BBS Toolkit

home *** CD-ROM | disk | FTP | other *** search

/ BBS Toolkit / BBS Toolkit.iso / qbbs / eft130.zip / EFT.DOC < prev next >

Wrap

Text File | 1992-03-31 | 199KB | 3,866 lines

EFT enhanced file transfer 31.03.92 22:36 Page i Table of Contents 1. Introduction.................................................. 2 2. Features...................................................... 4 3. Requirements.................................................. 9 4. Installation................................................. 11 1. Command line parameters................................. 11 2. Downloads............................................... 14 3. Uploads................................................. 14 4. FD_UPD,FILEDOOR.PRM..................................... 15 5. EFT.CFG...................................................... 16 1. LogFile................................................. 16 2. Colour.................................................. 16 3. Color................................................... 16 4. FreeFile................................................ 17 5. Protocol................................................ 17 6. PrivateUploads.......................................... 17 7. DefaultExtension........................................ 18 8. UploadLog............................................... 18 9. UpLogFormat............................................. 18 10. DownloadLog............................................ 18 11. DownLogFormat.......................................... 19 12. NoAreaNames............................................ 19 13. FilesCount............................................. 19 14. NoArchiveCredit........................................ 20 15. CDROM.................................................. 20 16. AskCDROM............................................... 20 17. DIZfile................................................ 20 18. ArchiveExtension....................................... 21 19. CheckDupes............................................. 22 20. NoSimilars............................................. 22 21. SysopPassword.......................................... 23 22. AutoSearch............................................. 23 23. DownloadHours.......................................... 23 24. TouchUploads........................................... 24 25. NoStatLine............................................. 24 26. TempDrive.............................................. 24 27. FileDoorDir............................................ 24 28. AskAnother............................................. 24 29. MinSpace............................................... 24 30. Unwanted............................................... 25 31. DescLen................................................ 25 32. MinBaud................................................ 25 33. FreeRatio.............................................. 25 34. CorrectKbytes.......................................... 25 35. TimeOut................................................ 26 36. BreakDir............................................... 26 37. SwapDir................................................ 26 38. ShutUp................................................. 26 39. BadFiles............................................... 26 40. YesNo.................................................. 26 41. UploadCredit........................................... 27 42. UpDayCredit............................................ 27 43. OldStuff............................................... 28 44. UlMultiply............................................. 28 EFT enhanced file transfer 31.03.92 22:36 Page ii 45. NoNegativeDownloads.................................... 28 46. KeepBroken............................................. 28 47. Unlinkbroken........................................... 28 48. MinGIF................................................. 29 49. MinPCX................................................. 29 50. LogStyle............................................... 29 51. LogLevel............................................... 29 52. InfoFile, ............................................. 29 53. InfoFileHeader ........................................ 30 54. UploadName............................................. 30 55. PICResolution.......................................... 30 56. EmbeddedCodes.......................................... 30 57. UseEGA................................................. 30 58. AutoTransfer........................................... 31 59. MaxLimit............................................... 31 60. TagFiles............................................... 31 61. TagFilesMacro.......................................... 34 62. HideFiles.............................................. 34 63. UserMacro.............................................. 34 64. Protocol............................................... 34 1. General............................................ 34 2. The protocol line.................................. 34 3. The interface line................................. 35 1. DSZ........................................... 36 2. Opus.......................................... 36 3. ErrorLevel.................................... 36 4. Other......................................... 36 5. CDS........................................... 37 6. Macros on the commandline..................... 39 4. The behavior line.................................. 40 1. ArcTest....................................... 40 2. ErrorLevel=................................... 41 3. GoodFile=..................................... 41 4. Opus11X....................................... 42 5. SendInfos..................................... 42 6. GetInfos...................................... 42 7. NoLeading..................................... 43 8. Resume........................................ 43 9. Cls........................................... 43 10. Window=...................................... 44 11. ArcWindow=................................... 44 12. SlowBIOS..................................... 45 13. LeaveUploads................................. 45 14. NofilesOK.................................... 45 6. Supported files.............................................. 46 1. System files............................................ 46 1. FILES.CTL.......................................... 46 2. BADFILES.CTL....................................... 46 3. LIMITS.CTL......................................... 47 4. FLSEARCH.CTL....................................... 48 5. FILES.EFT.......................................... 48 6. EFT.LNG............................................ 48 2. Display files........................................... 51 1. HLP_UP.A??,HLP_DOWN.A??............................ 53 2. UP_CMD.A??......................................... 53 EFT enhanced file transfer 31.03.92 22:36 Page iii 3. DWN_CMD.A??........................................ 53 4. EFT_UP.A??,EFT_DOWN.A??............................ 53 5. UPHINTS.A??,DWNHINTS.A??........................... 53 6. EFT_CMD.A??........................................ 54 7. BADFILES.A??....................................... 54 8. DNLDHRS.A??........................................ 54 9. RATIO.A?? ......................................... 54 10. RATIOK.A?? ....................................... 54 11. TOOSLOW.A??....................................... 54 12. STARTCHT.A??,ENDCHT.A??........................... 54 13. TODAYK.A??........................................ 55 14. PWDERROR.A??...................................... 55 15. TAGGER.A??........................................ 55 16. TAGVIEW.A??....................................... 55 17. TAGAREA.A??....................................... 55 18. EFTCHAT?.A??...................................... 55 19. BADPIC.A??........................................ 55 20. WANTFILE?.A??..................................... 55 7. Samples,Notes................................................ 56 1. Commandline Samples..................................... 56 2. General Notes........................................... 56 1. HotKeys ........................................... 56 2. Networks and Multitaskers ......................... 58 3. CD-ROMs ........................................... 58 4. RAM usage.......................................... 59 5. Fast Modems........................................ 59 6. Hidden files....................................... 60 7. Swapping........................................... 60 8. Limit Checkers..................................... 61 3. Trouble-Shooting and Questions.......................... 62 4. Maxima.................................................. 65 ┌────────┐ │ ┌─────┐ │ │ ├─┼──┬─┐ │ │ │ enhanced file transfer door │ │ │ v 1.30 └────────┘ Documentation and Software written by and Copyright (C) Michael Raus, Raus EDV-Systeme, 1991 All Rights Reserved Released 31.03.92 22:36 EFT enhanced file transfer 31.03.92 22:36 Page 2 1. Introduction --------------- Welcome to EFT v 1.30. EFT allows external file-transfer programs to be used for uploading and downloading with Remote Access Bulletin Board Systems of all versions and SuperBBS V 1.x. I don't think it is too much to call EFT the next step in BBS transfer managers when it comes to features and flexibility regarding uploading and downloading - But check for yourself in the feature list below! PLEASE NOTE: This is a rather large document - Instead of providing sparce documentation, I've tried to cover as much as possible here, in an attempt to avoid false bug-reports, so please study the documentation here before you start to whine. EFT is a child of FileDoor, the superb filetransfer manager, which was primarily made for Qbbs, and which was later adapted by several utilities to Remote Access, too. Stig Jacobsen of DAK software was the original author and he had ingenius ideas on how to improve the rather primitive filetransfer system, and the (still) buggy protocol drivers built into Qbbs,RA and (too bad) SuperBBS, too. For most features the credit has to go to Stig, and I want to state here that I think he is a superb C programmer. Since I am primarily a C programmer, too, I will try to get in touch with him to see if many hands make light work, especially since I heard that he has stopped supporting FileDoor. I would also like to state here, that EFT is a completely different program, and is in no way related to FileDoor in the way it is written. I neither had the source code to FileDoor, or any tool boxes to aid me - EFT is a piece of work created by my hands only. Anyway FileDoor is one of the rare BBS utilities that I have found to work very well and that was beta tested in a way all those superduper-zap-pow BBS utilities should get tested. (Hint!) EFT is searching for foreign support nodes outside Germany whose sysops have technological know-how, and are willing to assist users and other sysops in their country in the use and installation of EFT. Of course, support nodes get their key for free, and also they should not use any other file-transfer manager other than EFT. This job will surely take up some time. I have no need for support sites just sitting there doing nothing! SO please think twice before calling me. If you are interested, you can contact me at: Michael H. Raus The Wizard's Inn II BBS Line1: ++49,2307,21968 HST DUAL V.32bis Line2: ++49,2307,10012 HST DUAL V.32bis Line3: ++49,2307,22998 HST 14400 EFT enhanced file transfer 31.03.92 22:36 Page 3 Line4: ++49,2307,22999 Zyxel (soon) Please address all mail to 'System Operator' or 'SysOp'. If you are satisfied with EFT you should buy a key which is available for $20 US Dollars. If you register through national EFT support sites please add $5 for bank charges. Die Registrierungs-Gebühr beträgt 35.- DM entweder an mich direkt oder an EFT Support Germany I. The fastest way to get the key is to pay the money via TeleText/BTX to: The Wizard's Inn II BBS Volksbank Kamen-Werne EG Account/Konto: 501 64 64 400 Institute/BLZ: 443 613 42 Your key will be made available attached with a message at The Wizard's Inn II, the day your money arrives. The normal key will work with all future versions of EFT, and the key information (BBS and Sysop's name) is shown at the top of each screen, so include this information with your money order so I can quickly and easily generate your personal key. If it should so happen that EFT gets completely re-written or otherwise totally re-designed, you may be required to pay for an additional key, but until now, the $20 US dollars will bring you the latest EFT version from now until kingdom come. EFT enhanced file transfer 31.03.92 22:36 Page 4 2. Features ----------- For FileDoors users, I have included the features of FileDoor here and shown where I have made changes and additions to the FileDoor features. o EFT's .CFG file doesn't require a FILEDOOR.PRM, but is 100% compatible with FileDoor V 1.21! Simply replace the executables, rename the support files and there you are. Please note that if you want to make advantage of the enhanced features, then you will have to specify additional statements and parameters in your EFT.FG o Up to 32 upload, and 32 download protocols may be installed. o Free files. If you use X_List <tm> you'll be aware of the concept. It is files that your users get "for free", i.e. downloading a free file means that the download Kb won't be added to the user's total. As an additional bonus EFT supports FILES.CTL, which is originally a registered RA 1.0 feature. You may use both methods at the same time. o Users can choose to be automatically logged off after a transfer has been completed. o You have 100% control over the protocols. Name them as you wish, include or exclude any you want. There are 5 types of interfacing methods, which should allow just about any stand-alone file-transfer program to be used with FileDoor, including DSZ and those protocols following the standard Opus interface for external protocols. *Plus* EFT's CDS support for the superb MPt protocol from Microtech Systems. o Private files (not seen by the users) can be uploaded for SysOp only, if the user supplies a '/' as the first character of the description. *Plus* EFT's privatedir support: Private files may be moved across partitions and directories to any directory which you specify for private uploads, so your private files are no-longer added to your FILES.BBS when the next auto-update is run. o When up-/down-loading, you can make EFT add a default extension (ARC, ZIP, LZH, whatever you want..) if the user doesn't supply an extension when specifying a file. o If you use DSZ for ZModem uploads, a user can restart an aborted upload (after a carrier loss). This never worked correctly in FileDoor - it will work with EFT. If you define a protocol to be able of resuming aborted transfers, EFT will swap in the aborted files to the temporary upload directory across partitions and networks. EFT enhanced file transfer 31.03.92 22:36 Page 5 o Built-in FILESCNT. You have the option to update a "Download Counter" each time a file is downloaded, so that your callers can see which files are the most popular on your system. *Plus* the chance to define how your counters are to be separated from the remaining description. You could have [] or {} or <> or even <] or anything that you might want... o Special separate logfiles for uploaded and downloaded files. *Plus* free configurable log formats! Macros on the format line will be replaced with the actual parameters. This is very powerful as you can have the format you like or the format you need for further processing with statistics generators or whatever have we. o Rejection of uploads of duplicate files (files that already exists on your system). Saves you tons of diskspace, and loads of online- time for your callers. *Plus Phonetic antiduper! Ever got angry with users who upload XBTX_070.LZH even when there is XBTX_100.ZIP already somewhere on the board? The phonetic antiduper will keep track of those numbheads. o Rejection of uploads of non-archived files. Same advantages as for the dupe rejection feature. Plus Instant Archive-Checking! Ever got angry with users uploading archives with CRC errors? EFT will check the received files straight after they have been recieved, and gives credit only to those files which are 100% error free. Plus rejection of .GIF files with too low resolutions or number of colors (so no more CGA GIFs, which are older than my grandpa (and they are both already dead ...). The same goes for PCX files. In addition to this behaviour statement (arctest) there is Arcexitinfo which means that a small exitinfo file is created. The use for this file will be explained in the detailed section. o AutoSearch<tm> - Instead of just searching the current file area, you can instruct EFT to search all the file areas which the user has access to for the files he specified for download. EFT will keep track of all security features concerning files and file areas which the user has access to. o And all the standard features that any decent Door program has: Monitors carrier Checks inactivity timeouts Checks time-limit/download-limit Runs in local mode with no special provisions Handles ANSI/non-ANSI users Variety of anti-hacker devices built-in Etc. *Plus* EFT will swap out of memory to DOS, there is a colour chat mode with word wrapping (which will operate anywhere - menus, EFT enhanced file transfer 31.03.92 22:36 Page 6 warnings, etc., and leave the user at the same position when you broke in with the chat!). For ANSI users EFT has a build in full-screen split screen chat mode, and the users screen is completly restored when returning from the chat - regardless of where you broke in with the chat! Plus the ability to send special textmacro files via ALT-1 .. ALT-9. Plus the ability to send any file to the users side. o FileDoor has no equivalent feature! Advanced breakdir support: Generations of broken files may be stored, bringing back the biggest one when it comes to resuming. So even if there _was_ as misunderstanding between the protocol, EFT and the BBS, you may still recover your file from the break directory and not have the fear of loosing files. If the resuming was successful, you can direct EFT to delete all the older generations of the broken file from the break directory. o FileDoor has no equivalent feature! Automatic network support: If EFT detects a shared environment, it will lock any files which it is using if a user is online, and if another process is using any file which EFT needs, then it will tell the use of the fact and will wait a maximum of 30 seconds for the other process to release the file. o FileDoor has no equivalent feature! If a user drops carrier when giving the descriptions of uploaded files, EFT will put a definable description and move only the good files to your fileareas and give users access to them. If the descriptions were given before the transfer, then EFT will move the private files into the correct areas before exiting. o FileDoor has no equivalent feature! Multiple-line file descriptions. But as always EFT does it the enhanced way: You get SCROLLING prompts remote for file descriptions and the files-to-download prompt. Note the new parameters to the DESCLEN statement in EFT.CFG. o FileDoor has no equivalent feature! You can have up to 6 behavior windows to let users download only during special times a day, and those windows can overlap at midnight and each other ... o FileDoor has no equivalent feature! Full support of RA 1.0 BADFILES.CTL - giving Qbbs and Sbbs systems that feature, too. Plus support for BADFILES.ASC/.ANS. o FileDoor has no equivalent feature! Full multiline support: You can have one configuration file for all EFT enhanced file transfer 31.03.92 22:36 Page 7 the lines which run EFT. EFT will replace macros in the path specifications with the actual pathnames to the required line. o FileDoor has no equivalent feature! Foreign language support: As an additional feature, EFT will give you the chance to define more than just "Y" and "N" for answers to a Yes/No prompt, so that (for instance) a French user would be able to use "O" for Oui or "N" for Non. Plus full support for own prompts and menus + color support for language files. All hard-coded stings can now be defined. o FileDoor has no equivalent feature! "Download a special file" support for sending filelists etc.. If you call EFT with special parameters for this, the EFT will ask the user for the protocol to use and will send him the file specified on the command line. o FileDoor has no equivalent feature! There is support for password protected areas and file groups, specified by wildcards and pathnames. You can combine this with specific downloads and freefiles. This give full control for those who have user groups on their systems. o FileDoor has no equivalent feature! This is my favorite: ALT-H gives line noise simulation ;-) o FileDoor has no equivalent feature! The new behavior statement: EFT will send descriptions of the downloaded files from your FILES.BBS (works with AutoSearch), and will also collect descriptions for uploaded files from an ASCII file sent along with the main uploaded files. EFT will selectively inistialize or de-initialise the FOSSIL when ruinning protocols which do their own interrupt driven I/O (e.g. Tmodem). EFT will resume aborted transfers and swap in the right aborted file from any directory on any partition. There is OPUS 1.1x support, instant checking of uploaded archives of any style, selectable errorlevels to run awkward protocols, there is a special way of running protocols from batch files and still getting the right errorlevels, and much, much more. o FileDoor has no equivalent feature! Full-screen file tagger! Users can click on the files they want, they can browse up and down file-lists, sort them, search for files, list only new files, etc. This also works in global mode (where all the lists from all the areas the user has access to are combined to form one big list). The file tagger is also capable of multitasking EFT enhanced file transfer 31.03.92 22:36 Page 8 - it lets users select files while the tagger is still searching the filebase for more files to add to the bottom of the list. (see Norton Utilities FileFind v5.x), and it also lets users view the contents of files,archives and files within archives. o FileDoor has no equivalent feature! In addition to the full-screen tagger there is a kind of low-tech tagger available for those who not run ANSI compatible terminals. If a user specifies a filemask on the download prompt and gives an additional /P he gets prompted for every occurrence of the file and has several options to select from. For more details see section on tagging. o FileDoor has no equivalent feature! Full screen file browser! The tagger includes a full featured file browser which will also work within archives! It is easy to use: If you want to open a file, EFT will decide if it is an archive or not. If it is an archive, then it will show the list of files inside the archive. If it is not an archive, then EFT will show the contents of the file. Inside a file you can pageup/down, scroll up or down, or move to any location in the file. o FileDoor has no equivalent feature! Automatic Intercomm/Bimodem interface for full-duplex protocols with complete limit/ratio check, file descriptions, file moving, plus password proctected Bimodem sessions and private files support. o FileDoor has no equivalent feature! EFT will update USERON.BBS, to show exactly a user or the sysop on a different line what the another line is doing (FILE XFER, CHAT, DOOR). o FileDoor has no equivalent feature! EFT supports enhanced file specifications in all places, including FILES.CTL, FILES.BBS, and BADFILES.CTL. This means that if you specify *a*.*a*, then all the files with an 'a' anywhere in their filename will be returned. In FILES.CTL, if you had "f*r*i?t*.*z* /FREE", then free files given may be: FRAINT16.ZIP, FORTITTS.LZH, etc. If you had *3*.* /PWD=ArnieSchwarz, all the files with a "3" in the first part of their name would be protected by Arnold Schwarzeneger's favourite password! As with BADFILES.CTL you can also give a /UNWANTED statement on a FILES.CTL line to mark a file as unwanted. This feature has enourmous power, and can save lots of time for your users. o FileDoor has no equivalent feature! Intelligent LIMITS.CTL support - if ratios are out of range, then EFT will treat them as the value which describes download limits for higher baud rates of 19200 and above. EFT enhanced file transfer 31.03.92 22:36 Page 9 o FileDoor has no equivalent feature! EFT is the first BBS utility to be capable of moving its overlays into XMS to enable even 286 machines with HIMEM.SYS loaded to have high speed cached overlays. This may be disabled by setting the environment variable "NOXMSOVERLAYS" to any value - a CFG statement was not possible since the parser is already overlayed. o FileDoor has no equivalent feature! Several lines are allowed to refer to the same file in FILES.CTL. For instance: EFT*.ARJ /FREE EFT100.ARJ /PWD=noway QBBS*.* /UNWANTED means that all the files beginning with EFT in their name will be free files, but EFT100 will be protected by a password of "noway" - for instance, EFT099.ARJ will be a free file, but _not_ protected by any password, while EFT100.ARJ will also be a free file, but a user will have to enter the correct password of "noway" before they will be allowed to download it. BTW: QBBS*.* will be rejected. Has same effect as BADFILES.CTL. o FileDoor has no equivalent feature! You can use EFT as a replacement for the 'list new files' and 'search for file or keyword' function with optional tagging and downloading of the tagged files. o FileDoor has no equivalent feature! Also included is a full featured CD-ROM manager for read-only media. Files are only access when downloaded for full speed in every situation. You can even put pathes into your CD-ROM FILES.BBS to let files from diffrerent directories on your CD form one single area. o ok - can I stop the list? I'll describe the other features not mentioned here in detail later in the documentation ... 3. Requirements --------------- o An installed and working Remote Access of version 1.1x! Sbbs is also supported, so if you run a Qbbs system and want to run EFT, get a utility to convert to RA or SBBS and there you are. Note that you also have to convert the config files as EFT reads some information from them. o Dos 3.0 or higher - you *may* be able to run EFT with Dos 2.x, but I haven't tried it myself. (You should upgrade to DOS 5.0, bozo) o Some external file transfer protocols such as DSZ, CLink, JModem, OMLink, Kermit, HS-LINK, BiModem etc. - whichever you want or EFT enhanced file transfer 31.03.92 22:36 Page 10 desire! The transfer programs are NOT includeed with EFT for a good reason - Including protocols in the archive which you probably already have (and perhaps in later versions) would increase the size of the archive by 200Kb or more. o I do not know exactly how much memory is needed my EFT to run. In fact, at the time of writing, EFT has not yet been FULLY optimized. I run it under RA in a 450Kb environment (altogether with RA). I expect EFT to run in @250K of RAM. I'll see what can be done to reduce the RAM needed in one of the next versions. In actual fact you are most likely to have more than enough memory after RA has swapped out of memory. o You may find EFT more useful, if you have a modem and a telephone-line handy, even though these items aren't required. And you should be connected to a energy source to put some life into your equipment ... EFT enhanced file transfer 31.03.92 22:36 Page 11 4. Installation --------------- Before installing the program, please read this documentation completely, and any READ.ME files supplied within the archive. The program is installed with a type 7 or type 15 command in each of your file menus. Type 7 is preferred - it is faster and simpler, but it also uses more memory if you do not specify the *M memory swap feature. To get type 15 to work with EFT downloads, you must enable AutoSearch<tm> (described below). EFT supports the following parameters: 1. Command line parameters -------------------------- -#<name and path of parameter file> ... Commandline parameter -#<name and path of paramfile> lets you define a parameter file from which EFT shall read the commandline parameters if your EFT commandline exceeds the BBS's capabilities. -# can be mixed with other commandline parameter. Each given parameter will be executed. Also the format of the parameterfile is free. Simply give the parameters as if you had given them on the commandline. There can be several parameters on one line. Max length is 255 chars. There can be unlimited lines. -p<n> ... defines the COM port to be used. <n> should be replaced by 1 for COM1 or 2 for COM2 etc. You should combine this with RA's *P macro: -p*P -p defaults to local mode (!!) if not given. -t<n> ... passes time left the user has online today. If this ins not given, then EFT will find the remaining time from the EXITINFO.BBS. You should use this with RA's *T macro: -t*T. -n<n> ... passes the number of the line EFT is working on. This is to enable EFT's multiline support so unique filenames and directory names are used to prevent the lines from disturbing each other. This should be used with RA's *N macro: -n*N -a<path> ... this specifies the path to the actual file area from which files will be downloaded or to which the files will be uploaded. A trailing backslash in not necessary, EFT will ad one in you leave it out. WARNING!!! If you leave this parameter out, EFT will use the directory which it was started from. in which case, if you started EFT from your RA system directory, everyone could EFT enhanced file transfer 31.03.92 22:36 Page 12 download your system files!.. Be sure to set -a to an appropriate value. This may be used in conjunction with RA's *0 macro: -a*0. Make sure that your path does not begin with U or D otherwise EFT will recognize a -au /-ad parameter. If you have your fileareas on drive D: or U: you will have to assign it to another drive char, or use -ad / -au respectively. Beware of omitting -a when using AskAnother Switch! -au<path> ... if you want your users to be able to switch from download mode to upload mode inside EFT this parameter lets you specify the upload path. For example users start EFT in download mode, and download from filearea "C Programmers". If they switch inside EFT to upload mode all their uploads will go into "C Programmers". To have uploads go into a special path use this one. -ad<path> ... same as above - but for download mode. -w<password> ... Tells EFT that this area is password protected. As the first operation EFT asks the user for the password specified after the -w commandline parameter. 3 attempts are allowed then the user is returned to the BBS. Case does not matter. -c<path and name of config file> ... specifies the path and name of the file EFT has to use as its .CFG file. This can also be in a shared directory for use by several lines. See also the $1 macro for pathnames in shared .CFG files. E.g.: -ceft.cfg or -cd:\bbs\1\eft.cf1 -du ... tells EFT to prepare for uploading (u). Only the protocols defined in EFT.CFG as upload protocols are selectable. -d uses the path set by -a or if that was not used, the directory EFT was started from. -dd ... tells EFT to prepare for downloads (d). Only the protocols defined in EFT.CFG as download protocols are selectable. -dd uses either the path set by -a, the actual path EFT was started from, or AutoSearch (described later). If you use AutoSearch, you may omit -a. -dd[!]<name of download file> ... directs EFT to transfer only that specific file. The user is asked for the protocol to use and the transfer is started. Useful to transfer EFT enhanced file transfer 31.03.92 22:36 Page 13 filelists or hint files. Specific files can be password protected or can be free files, too! The path to the specific file is given via the -a parameter. If you add a '!' before the filename, then EFT will send the file even if the file is not in a FILES/PFILES.BBS file. -f<protocol char> ... Parameter -f lets you force EFT to lock a special protocol, so that you can use a standard BBS menu as the EFT "select method" screen and call up EFT with the protocol locked. With the protocol locked EFT will immediately go to the "select files to download" or "give first filename" prompt. There are additional display files for you to give optionally additional information that will function like the general DWNHINTS.*/UPHINTS.*: Example: ZU.* will be used in upload mode if -fZ is given on the commandline MD.* will be used if in download mode and -fM was given. -lp<path and name of language file> ... Lets you define the name and path of the EFT language definition file. -ln<name of language> ... Lets you define the name of the language. -tag ... This automatically brings up the filetagger in download mode after the user selected a protocol. No hintfiles or build-in download hints are shown. This can also be combined with forced protocols. -TAG has some sub-functions: If you want the tagger to come up with the new date prompt give -TAG:DATE. If you want the tagger to come up in filemask-search use -TAG:MASK. If you want the tagger to come up in global mode (selecting from all areas) -TAG:GLOBAL. If you want the tagger to come up in new files mode with the users last-on date set use EFT enhanced file transfer 31.03.92 22:36 Page 14 -TAG:LAST. And last -TAG:KEY lets the user give a search keyword. Forced tagger behaviours can be combined: Example 1: EFT.EXE ... -tag:global -tag:key Will first ask for a key work then switch to gloabl mode. Example 2: EFT.EXE ... -tag:global -tag:last -fZ is an replacement for the list-new-files function in RA/SBBS - PLUS immediate tagging and downloading via Z-Modem. The FileDoor switches '-h' and '-?' are no longer supported by EFT. You have the documentation for this. 2. Downloads ------------ The optional data field should be as follows for downloading: EFT.EXE -dd -a<downloadarea> -p*P -n*N *M The above example assumes that you have placed EFT.Cfg and EFT.Exe in the current directory. If EFT.EXE isn't in the current directory, you must specify the complete path to it (refer to the RA documentation). Also, this example assumes that you have EFT.CFG in the current directory. The '-dd' is a switch to tell EFT to "Do Downloading". The <downloadarea> is the complete path to the area from which the user is going to download from. E.g. -aC:\FILES\QUICKBBS\. It does not matter whether you include the trailing backslash. You may also use the RA *0 macro for template paths (see RA.DOC). WARNING!!! The path EFT was started from will be used if you omit the parameter, sending the user all of your system files upon request. The same goes for uploading, so be sure to give -a. 3. Uploads ---------- Uploading is pretty much the same: EFT.EXE -du -a<uploadarea> -p*P -n*N *M EFT enhanced file transfer 31.03.92 22:36 Page 15 The '-du' tells FileDoor to "Do Uploading". The <uploadarea> is the complete path to the upload file area. This parameter should always be given, even with AutoSearch - otherwise, EFT would place uploads in the directory it was started from. You can use RA's *0 macro for template paths. 4. FD_UPD,FILEDOOR.PRM ---------------------- FD_UPD is not needed anymore. Free up some disk space and delete it. FILEDOOR.PRM is not created anymore. Instead the EFT.CFG file is read every time EFT is called. It is slower, but it takes only seconds to read and interpret the .CFG file, and so I did not see the need to compile it to a binary file. You can speed up the reading of EFT.CFG by removing all the comments and the statments which you do not intend to use. EFT enhanced file transfer 31.03.92 22:36 Page 16 5. EFT.CFG ---------- The configuration file (usually named EFT.CFG) informs EFT of your systems's configuration. You cannot run EFT without it, but there is a sample configuration file included within the archive to ease the pain... You may include blank and comment lines in the configuration file, which are ignored. Comments are inserted by placing a '%' anywhere on the line - anything following a '%' is ignored. Case in not considered significant in the configuration-file, but you should be aware of that some transfer programs may be case sensitive - DSZ for instance. Keywords can only be repeated a fixed number of times (to save memory) - I'm not going to list the limits here, but if you repeat any keyword too many times ('Protocol' for instance) EFT will terminate with a friendly message stating what the maximum limit for that keyword is. That will also be logged to the log file. General note: If you want, you may specify PRN/LPT1/LPT2... as the filename for a logfiles to send it to a printer. Note! that EFT doesn't check that the printer is ready, so if it runs out of paper, or a jam occurs, your system will wait until you come and answer the well known DOS "Abort, Retry, Ignore" prompt. Also, you may use the $1 macro to be replaced with the number of the line EFT is running on. For sample uses of the keywords, please study the supplied .CFG file. The keywords currently supported are: LogFile <path and name of logfile> ... This names the EFT logfile. Whenever a user transfers a file, EFT writes an entry to this file. If you don't include a logfile statement, then there won't be a logfile (it will go to the NUL device). you can freely define the format of the logfile. Colour and Color <ANSI ESC sequences> ... These two keywords do the same thing : they define which colour to use and where: file tagger filedates ! file tagger filesizes ! ! file tagger filenames ! ! ! highlite ! ! ! ! ! ! lowlite! ! ! ! EFT enhanced file transfer 31.03.92 22:36 Page 17 ! ! ! ! ! Colour [0;32m [1;33m [1;33m [1;35m [1;32m ... ... [1;36m [1;37m [1;37m [1;31;40m ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! file tagger area ! ! file tagger cursor ! file tagger tagged files file tagger filedescriptions The ANSI colour strings are each not to exceed 10 characters in length, and are sent raw to the modem prefixed by an escape character. The colour codes can be found in the PC-DOS technical reference manual, or in various files that may be found on BBSs. FreeFile <path and/or filename with or without wildcards> ... If you wish to have any "free files" available for download, you name them here (one file per line - repeat the statement as many times as needed). A "free file" is a file that won't be noted in the users download. This could be your "AllFiles" list, the RA users manual, or any other file that you want to persuade your users to download. Free files can be a single file, like "FreeFile TIC_LIST.ARC". For single files, you cannot and should not specify a path. Free files can also be a wildcard specification, like "FreeFile C:\Files\Info\*.*". For wildcard specifications you can specify the entire path to the free files, otherwise the wildcard definition is relative to the actual used path. Maximum is 16 FreeFile statements, because EFT has full support for RA 1.0's FILES.CTL (described in the supportfiles section) those 16 statements are only to keep compatibility with FILEDOOR.CFG. Free files are shown on a special line on the last chance menu. Note that EFT supports enhanced filemasks like *3*.ZIP or similar every time it comes to pathes or filemasks. Protocol ... This is quite complicated, and is described in detail below. PrivateUploads [<path to private uploads>] ... If this statement is enabled, your callers can make a "SysOp-only" upload, by supplying a '/' for the first line of the description. Private uploads are posted in the usual upload directory (as given on the command line), but the description of the uploaded file is placed in the file PFILES.BBS (P for Private) in the upload directory, EFT enhanced file transfer 31.03.92 22:36 Page 18 where it may be later viewed by the sysop, or any user who has access to private files in that area. If you specify an optional path after the PrivateUploads statement, then private uploads and the PFILES.BBS are placed in that path, and not the normal upload directory. This works at high speed on one partition (only renaming those files to the new path), and across partitions (copying with maximum available copy buffers). DefaultExtension <fileextension, 3 chars max> ... This just names the extension that EFT will add to filenames if the user doesn't supply an extension. If you leave this statement out, EFT will not apply a default extension. UploadLog <path and name of logfile> ... With this keyword enabled, EFT will keep an extra log-file to which all uploads are logged. I save this logfile (unlike RA.LOG which is deleted when it gets too huge), so that if I later discover that a user uploaded a non- PD/ShareWare program, I can look into this file, and catch the guy. The format of the logfile can be defines with the following statement: UpLogFormat <format line with or without macros> ... UpLogFormat defines the format of the UploadLog file. Give whatever text you like and use whatever macro you want out of the following: #BBSPATH ... path of updated FILES.BBS/FILES.x #CPS ... CPS rate #EXT ... fileextension #NAME ... filename #PATH ... path to actual area #SIZE ... filesize #USERFIRST ... users first name #USERLAST ... users last name #LINE ... BBS line EFT is working for #BONUS ... size of the file after passing the bonus routines on uploading Macros (can be used up to 255 times each on one line). This is powerful: You can also generate logfiles that you can let process further with statistics generators or log analyzers. DownloadLog <path and name of logfile> ... Exactly the same thing as "UploadLog", but this one of course goes for downloads instead. You can set both to point to the same file if you wish. EFT enhanced file transfer 31.03.92 22:36 Page 19 DownLogFormat <format line with or without macros> ... Exactly the same thing as "DownLogFormat", but this one of course goes for the download logfile instead. NoAreaNames ... While searching through your file areas, EFT will display the name of each area. For 2400 baud users this can be slow. NoAreaNames will show dots in the place of area names. FilesCount [<char for open brace> <char for close brace>] [/NULL] With this keyword enabled, EFT will count the times a files is downloaded from your system. It places that number at the beginning of the file descriptions in FILES.BBS or PFILES.BBS, so that your callers can see which files are the most popular on the system. You can define how EFT should separate this count from the rest of the description. As this operation may cause a slight increase in your caller phone-bill if you have hundreds of files in your FILES.BBS or PFILES.BBS I implemented a cached FILES.BBS updater, that uses up to 64k of I/O buffer for FILES.BBS processing. As my test showed, this is lighting fast, and since it is so fast, I have made the FILES.BBS updater to additional maintenance to the FILES.BBS files, such as deleting dupes, etc., to keep the FILES.BBS or PFILES.BBS files respectively as beautiful at the SysOp himself. Use the pipe symbol (|) to tell EFT where to begin the file descriptions. For example: Example: Filescount > < | may produce: SCHNAGEL.GIF >000< Schnagelbaer eats fish Example: FilesCount < ] will cause the download counter in your FILES/PFILES.BBS to look like this: SCHNAGEL.ZIP <1] Picture of a cute dog WUPDICH.LZH <12] Curious stuff If you only specify FilesCount without the two additional parameters EFT's counters will default to []. In general when updating FILES.BBS EFT reads it, writes a temporary file named EFTFILES.x, deletes FILES/PFILES.BBS, and EFT enhanced file transfer 31.03.92 22:36 Page 20 renames EFTFILES.x to FILES.BBS. This way, if EFT or your system crashes, you can still recover the original FILES/PFILES.BBS (x=number of actual BBS line). Please note that if you want 0 padding of download numbers (i.e. fill up space in the counter with preceding zeros), you must specify /NULL on the end - it is not default. NoArchiveCredit <percent> ... The argument to this statement is a number which is the percentage of credit a caller will get for uploading a file whose extension does not match one of those given in an ArchiveExtension statement. For example, if you have NoArchiveCredit 60 in your CFG file, and a caller uploads the file JUUHUU.COM which is 80kb in size, EFT will see that it is not a recognized archive type, and so will only give the user credit for an upload of 48Kb (80kb*60%). CDROM <filearea number> <fileareanumber> ... Defines fileareas to be on a CDROM. This enables the enhanced FILES.BBS format for those areas: <path+name> <filesize> <filedate MM-DD-YY> <description> You can still use the old-fashioned way of installing read-only media into RA/SBBS, but neither will you be able to let files from several pathes form one area, nor you get the performance you would get using the EFT CDROM manager. Define up to 200 areas. You can use several CDROM lines. Example: CDROM 150 151 152 153 154 154 155 156 157 158 159 AskCDROM ... Ask the user if he wants to skip your CDROM areas every time a filesearch starts. See EFT.LNG line 227 DIZfile <filename without path> ... If you want EFT to check every uploaded archive for a (D)description (I)n (Z)ip file, you must define the name/s of the DIZ files here. 16 files is maximum, and whatever file is found first EFT extracts that file and puts its contents as the file's description into FILES.BBS. Wildcards ARE ALLOWED, but NO PATHES! The information from the DIZ file is truncated at 230 chars to fit FILES.BBS. in any case EFT will first look for an uploaded infofile FILES.EFT and will take descriptions from that file first. If that fails DIZ processing starts. Use up to 16 EFT enhanced file transfer 31.03.92 22:36 Page 21 different DIZfiles. ArchiveExtension <3 chars extension> [<cmdline for arctest>] ... ArchiveExtension supplies an extension which represents a legal archive type which is supported on your board, and which a user will be given full credit for if he uploads a file of this type. In addition if you give the second parameter, it is taken as the command which should be executed when a file of this extension is received, and you enabled the instant arccheck feature for the used protocol using the behavior statement (described later). You can use $1 as a macro, which is replaced with the name of the actual uploaded file on runtime. EFT searches the DOS path for the called program. You can also skip .EXE or .COM extension from the arctest commandline. Batch files may also be run here to test the given archive's integrity. Use the *C macro, which is replaced with the name and path of the active command processor (EFT uses the COMSPEC environment variable for this, so be sure that you have set it correctly). When running batchfiles with the *C macro EFT switches to goodfile handshaking, because the returned errorlevel from batchfiles is always zero, and so you get an OK even on bad archives. The solution is the mentioned goodfile handshake: Let your batchfile create a file called 'GOOD.', if it thinks that the archive is ok and should be moved to your fileareas. If you used the *C macro and EFT finds the file 'GOOD.' (which contents is ignored), is assumes that the batch run was successful and moves the tested archive to your filearea. If you do not use the *C macro EFT switches to standard errorlevel handshaking (zero=successful, non-zero=corrupted archive). This is powerful: Imagine running virus scanners here, or you could put in your BBS headers or what ever you like: It's all automatic and its done right after the file appeared on your system (no need to wait until the next household event), so the next user who tries to download the archive, which was uploaded some minutes ago gets an archive without CRC errors and your BBS's commercials in it, and that's guaranteed! For those who want to have different headerfiles for uploads to special areas, there is the *9 macro which is replaced by the number of the actual filearea, with preceding 0s to give the correct significance in relation to the number of used file areas. For example: EFT is working in filearea number 5, and e.g. 7 areas used: *9 will be replaced e.g. with '5' 19 areas used: *9 will be replaced e.g. with '05' 125 areas used: *9 will be replaced e.g. with '005' This is to correctly compare strings in batchfiles. See EFT enhanced file transfer 31.03.92 22:36 Page 22 the sample batch file, which is included in the package ... If arctest is enabled, EFT will check the size of the file after executing the arctest commandline, and if the size is smaller than before then that samller size is given credit for. So if you want to strip those annoying, unwanted advert files that some sysops put into their files, there won't be any credit given to the uploader for those stripped files. For in my opinion anyoone who puts commercials into files except in the archive header needs a good kick up the ass. EFT will strip them anyway, so don't put them in. CheckDupes ... With this keyword enabled, EFT will do A.I. work in an attempt to avoid your caller uploading files which are already present on your system. For non-batch uploads (for instance ZModem), EFT will scan all the file areas after the user enters the file which he is going to upload. If that file already exists on the system, EFT will print a message and refuse to start the upload. For batch uploads, (for example XModem) the user is given the opportunity to enter the names of the files which he is going to upload. If he chooses to enter the filenames immediately, EFT will scan the file areas to check to see if any of the files already exist on the system, and abort the upload if any of the files are on the system. If th user does a batch upload without entering the file names beforehand, EFT will scan the file areas when the upload has been completed, and the user will not be given credit for any files which have been duped. EFT will scan _all_ the file areas on the system, not just the ones the user has access to, and it gets its information on what files are available on the system from the directory, and not from the FILES/PFILES.BBS files. This is slower, but if you have orphans on your system (files not yet in the FILES/PFILES.BBSs), dupe checking would fail. NoSimilars ... This will engage the phonetic anti-duper. EFT will check all the FILES/PFILES.BBS for file which sould similar to files which were given by the user for uploading. If the user tries to send an older version of a utility which is already available on the board in a later version, he will get a message stating that there may be a dupe conflict with a file which has a similar name and/or a similar description. The user then has the chance to reenter the filename, ignore the warning, or to abort the upload. This interactive dupe checking is performed only on areas the user has access to because otherwise, he may get dupe messages on files that are in hidden areas and which he should not know about. After the upload completes, the anti-duper checks again, but this time, it won't ask the user and won't check for similars - only for exact dupes, EFT enhanced file transfer 31.03.92 22:36 Page 23 so users still have a chance to upload a file even with a name similar to one of the files already on your board. SysopPassword <Password> <Seclevel> ... If you enable this, if a user has the correct level, he may enter "//" at the download files prompt, and if he then enters the correct password (which is the parameter to this statement), then he may specify full pathnames for files which he wants - i.e. any file which exists on your hard disk, so be careful about to whom you give the password and the appropriate level... AutoSearch ... Like PCBoard and others, EFT can automatically search all the file areas for the wanted files when a caller initiates a download session, instead of just the current area like QBBS, Opus, etc. Even though it takes longer to find the specified files, there are still advantages, eg.: o Your callers do not have to worry whether they are in the right area or not before starting the download. This is especially helpful for new users. o They can download more than one file from more than one area at once. o If you use EFT with AutoSearch enabled, and install EFT from a type 15 exit, it will use far less memory than if it were run from a type 7 exit, since RA, EFT and the protocol need not be in memory at the same time. Autosearch is necessary if you run EFT from a type 15 exit from RA. Naturally, AutoSearch will limit its search to those areas and files to which the user has access. Please note that using AutoSearch means that you have to make sure that you have no duplicate file names available for downloading because otherwise you callers would be very confused when they try to download one of them... DownloadHours <start hour of download allowed> <stop hour> ... This works pretty much like the downloadhours option in RACONFIG. The two hours given may span midnight. When a user tried to download outside the given hours, EFT will try to display DNLDHRS.A??, but if it can't find that, then it will display a standard message to the user. You may have up to 6 behaviour windows, which can overlap each other, switching on and off downloading during the day. EFT enhanced file transfer 31.03.92 22:36 Page 24 TouchUploads ... Some file transfer protocols (most batch protocols - Zmodem, for instance) preserve the original file date and time stamp when uploading. This is not always useful, as the Newfiles function in RA won't work properly. To fix this, EFT will 'touch' (i.e. set the file's date/time stamp to that of the current date and time) all uploaded files if you use this keyword. NoStatLine ... If you don't like the status line (I can't imagine why not - it doesn't scroll off the screen like in FileDoor...), you can turn it off by including this keyword in the configuration file. TempDrive <drive and path> ... Sometimes EFT needs to create a temporary file (i.e. when using `$3' in command-lines). With this keyword you can instruct it as to where to put these temporary files - if you have a ramdisk, it will speed EFT up. If you use a CD-ROM, then make sure that you tell EFT to put the temporary file on the hard drive, and not on the CD-ROM!. Use as follows :- TempDrive <drive and path>, e.g. "TempDrive C:\EFT\TEMP". The default path for temporary files in the path where EFT was started. FileDoorDir ... This names the directory where EFT can find all its external support files (except the configuration file). This includes DNLDHRS.A??, EFT_DOWN.A??, EFT_UP.A??, etc. If you don't use this statement, EFT will look in the current directory. For multiline systems, this can be a shared directory. AskAnother [SWITCH] ... Will cause EFT to ask the user if he/she wants to perform another file-transfer after completing the previous one. If you put the optional parameter SWITCH on AskAnother's line, users will be allowed to switch from upload to download mode and vice-versa. Of course limit checkers stay active when changing from upload mode to downloading. EFT will deny access if the user has exceeded his limit. MinSpace ... This is the minimum amount of space which must be available before EFT will allow uploads. The default is 100k, and if you are on FidoNet, remember to leave space for incoming mail. EFT enhanced file transfer 31.03.92 22:36 Page 25 Unwanted <filename with or without wildcards> ... "Unwanted <filename>" will make EFT delete the given file if found in the upload-directory (when an upload is completed). This is handy to get rid of logfiles created by transfer programs. Wildcards are allowed. Desclen <max length of description for uploads> [position to scroll from] [amount of chars to scroll] ... This one is to restrict the maximum length of descriptions. Minimum=10, Maximum=77, EFT automatically adjusts the maximum description length if FilesCount is enabled. Parameter 2 if non-zero defines from what length the input prompt has to scroll. Parameter 3 determines how much chars are scrolled. The more chars are scrolled the smoother it gets! Example for smooth scrolling prompts: Desclen 255 73 40 No scrolling: Desclen 77 0 0 MinBaud <minimum baudrate to use EFT> ... This is the minimum baud rate which the user must be online at to use EFT. FreeRatio <Number of free files> <number of free kbytes> ... This is the number of files and/or kilobytes which a user may download before being subjected to ratio checkers, so that EFT will allow new users to download at least one file, even if the ratio is 1:1 (otherwise new users would have to upload first). CorrectKbytes <trigger level kbytes> <maximum reduce kbytes> ... Use this is you have any users on your board who need to take or give a large amount of files from your board. RA and SBBS are limited to 64Mb up and download kbytes, so if a user happens to upload 65Mb to you, RA/SBBS will wrap the amount around to 1Mb, confusing your ratio monitor. EFT will correct this when the value given to the first parameter of CorrectKbytes is exceeded by someone's download kbytes. In this case, EFT will subtract from that amount as much kbyte as given as the second parameter, depending on the ratio settings: E.G. if ratio on k is 1:2 EFT enhanced file transfer 31.03.92 22:36 Page 26 correctkbytes may take 4000k from the users upload account and 8000k from his download account. Therefore the first parameter must be greater than the second! EFT will monitor uploaded kbytes in the same manner. TimeOut <number of seconds for timeout> ... This is the number of seconds of inactivity which will cause EFT to hang up. FIleDoor used to print a message saying "Are you there?" if it was close to a timeout, but that was a rhetorical question, and confused users who answered the question with a "Y" or an "N", because FileDoor would then take that as a response to the original prompt. EFT will sound a beep every 2 seconds when nearing a timeout so as to wake up the user instead of asking rhetorical questions. (see ShutUp statement) BreakDir <path of breakdir> ... This is the directory EFT will use for aborted transfers etc. This can be on any partition since resume moves files across partition borders. On multiline systems this can be a shared directory. The default is the root dir of the drive EFT was started from, so you better give a different breakdir ... SwapDir <path and name of swapfile> [FORCED] ... This is the complete path and filename to EFT's swapfile. The $1 macro will be replaced by the actual line number which EFT is working on, if you wish to use it. If you have FORCED as a second parameter on the SwapDir line, EFT will be forced to swap to disk, if it has to run in an environment which is unstable when doing advanced swapping to RAM devices. ShutUp [start beep 24h format] [stop beep 24h format] ... Tells EFT not to echo ^G characters to the sysops console (useful for night operation or nervous SysOps). You can also define a start and stop period in which EFT will beep on your end. The defined behaviour window can cross midnight. BadFiles <path and name of BADFILES.CTL> ... This is the path\filename to RA 1.0's BADFILES.CTL (fully supported by EFT) : it is a files/pfiles.bbs style file with wildcards and pathnames allowed internally. All of the files matching a line in BADFILES.CTL (or whatever name you want) will be rejected by EFT if a user tries to upload one of them. YesNo <YescharsNochars> ... EFT enhanced file transfer 31.03.92 22:36 Page 27 This is to help users whose first language is not English. The parameter consits of one word with no spaces. The first half of the word consists of all the characters which you would like EFT to determine as a "Yes" answer to a Yes/No question, and the second half as a "No" response. Case is ignored. The default is YN, which is always active. Sample: YesNo OJNN Allows French and German responses, in addition to the Y and N of English responses UploadCredit <timefactor> ... The parameter to this is the factor by which the time the user spent uploading is multiplied by and added to the user's remaining time. If it is 1, the user will just get "refunded" the time he took uploading. If, for example, it is 2, the user will get twice the time back he spent uploading. The default is 0, so no time will be refunded unless you add this parameter. UpDayCredit <days> <percent> ... You can let EFT determine the amount of credit that is given to an upload by its age. If a user uploads a file that is younger than <days> days he will get <percent> percent of the whole filesize as upload credit. If you specify 100 nothing special happens, normal credit is given. If you specify 150 the user will get 50% extra bonus for uploading brandnew stuff. If a file does not fit in any of the table entries it will be rejected (zero credit). If you want to give e.g. at lease 5% for every file regardless of it's age give 'UpDayCredit 65535 5'.If the upload is an archive, EFT will determine the UpDayCredit from the defined day period that matches most of the files in that archive. Warning! In order to work correctly on NON-archived uploads you must install your protocol drivers to not touch the uploaded files but to keep the original date! Also you must not use the TouchUploads statement. Max 16 statements. Example: Using that table below will reject all files that are older than 1 year. Files younger one year get at least a credit of 10% of their real size. Files younger than 2 weeks will get bonus of 50% and so on. UpDayCredit 14 150 UpDayCredit 60 100 EFT enhanced file transfer 31.03.92 22:36 Page 28 UpDayCredit 120 80 UpDayCredit 200 50 UpDayCredit 356 10 OldStuff <Path> ... Your users will love this one: New statement OLDSTUFF <Path> in EFT.CFG let's you define a path to which old uploads have to go. EFT will show EFT.LNG line 225 and will not give any credit to the uploader. The text from EFT.LNG line 225 is added to the uploaders filedescription. An upload is OLDSTUFF if it does not fit in any age-class you would have defined using UpDayCredit. Suggested setting: OldStuff OLD SHIT -=> NO CREDIT AT ALL! <=- UlMultiply <security> <percentage> ... 16 of these statements may be specified. When these statements are specified, a user with security <security> will have his upload KB multiplied by <percentage> when he uploads a file. For instance, if "UlMultiply 30 200" is specified in the configuration file, then a user who has a security level of 30 and who uploads a 100Kb file, his upload Kb will be updated by 200, rather than 100, since the percentage was set to 200%. You may use values of less than 100 if you feel so compelled to do so.... NoNegativeDownloads ... NoNegativeDownloads prevents EFT from taking uploads as negative downloads so extending the users daily download limit if he uploads something to you (like FileDoor 1.21 did it). With NoNegativeDownlaods disabled Users will gain uploads as a bonus download limit. With NoNegativeDownloads enabled EFT will behave like the RA/SBBS internal protocols. KeepBroken ... This tells EFT to keep generations of a file which are incomplete - i.e. if a user tries more than one time to upload a file, and fails each time, then generations of the same file, some more complete than others will be kept, so that when the user tries again with a protocol which has resume enabled, the largest of these generations (the most complete file) wil be copied into the upload directory, so that the user can resume from there. UnlinkBroken ... EFT enhanced file transfer 31.03.92 22:36 Page 29 This tells EFT to delete all generations of an incomplete file/archive after that file is successfully uploaded, so as to free some diskspace. Note that it is not the opposite of Keepbroken. MinGIF <Min X resolution> <Min Y resolution> <Min colors> ... This tells EFT to reject all uploaded GIFs which have less than the specified resolution and/or number of colours. No upload credit is given to those files which have less than the specified resolution/colours. MinPCX <Min X resolution> <Min Y resolution> <Min colors> ... This does the same as MinGIF, except for PCX files. LogStyle [OPUS] or [FRONTDOOR] or [SBBS] ... This describes how the logfile that EFT creates looks like. You can make it look like an OPUS or FRONTDOOR/QBBS or SBBS logfile. LogLevel [RAW] or [MEDIUM] or [WELLDONE] ... This describes how much information EFT puts into the log. Default is WELLDONE for debugging purposes. InfoFile <name of FILES.EFT> or "<TIME>" ... If you are going to use GetInfos or SendInfos as the behavior of your protocol drivers, InfoFile gives you the opportunity to change the name of the file in which the BBS descriptions are sent along with the downloads, and from which upload descriptions are retrieved (if found). Neither wildcards nor paths are allowed. Max 12 chars. Note! Users must know which name you assigned to be used as the InfoFile, when you use the GetInfos behavior! A good place to put such information is either on the protocol selection menu or some of the help files. If you specify the word <TIME> (including the <> chars), EFT will generate a filename for you consisting of the day of week and time of the transfer, so if users do several transfers in a row, and use protocol drivers, that are not capable of renaming already existing files (or users have installed them wrong way), this is for you. Make sure that the maximum files that are transferable in one sweep is set properly if you expect an infofile to be transmitted, too. Example: SU012259.EFT (Sunday late night show ;-) <TIME> is not allowed with GetInfos, and FILES.EFT will be automatically assumed, so you can have <TIME> for down- and FILES.EFT for uploading. EFT enhanced file transfer 31.03.92 22:36 Page 30 InfoFileHeader <name and path of FILES.EFT-header file> ... If you are going to use SendInfos as a behavior of your protocol drivers, InfoFileHeader is the name and path of a file to put first into the infofile. This could contain special hints, commercials or info about your system. UploadName [Security] or [Flag] ... Makes EFT add the name of the uploader to the descriptions of the uploaded files. Note that with UploadName enabled the description can grow above DescLen (see there). UploadName has three versions: UploadName will log every username on uploads UploadName <Seclevel> will only log the usernames with the upload descriptions of users having a security below the given parameter UploadName <Flagsetting> same as above, uses ONE free definable flag Additional parameter HANDLE makes EFT log the user aliases (handles) instead of their real names. Attention! I think this is only possibble on RA100 systems as the SBBS exitinfo does not contain the userhandle. Example: UploadName A6 HANDLE or UploadName 60000 PICResolution ... Makes EFT add the resolution and number of colos to the descriptions of uploaded GIF and PCX files. Note that using PICResolution means that the description can grow above DescLen (see there). EmbeddedCodes ... This will enable EFT's support for embedded control codes used in support files. With this option set you can use RA's control codes to insert information like the user's name, files ratio, kilobytes downloaded, or whatever you like, and put them anywhere you like (e.g in EFT_UP/DOWN.A??) UseEGA ... If this option is set, EFT will automatically use 80x43 or 80x50 text mode if your computer has either an EGA or VGA EFT enhanced file transfer 31.03.92 22:36 Page 31 graphics card. EFT will return the screen to its original display mode on return to the BBS. AutoTransfer ... With AutoTransfer enabled EFT will allow your users to sent files with requested files or files to be uploaded including descriptions to your BBS to let EFT process them automatically as if the user had typed in all of the files. Of course this will work with the build in limit-checkers and dupe-checkers. In addition behaviour sendinfos and getinfos will work, too. AutoTransfer works great with automatic logons via terminalprogram scripts. AutoTransfer will enable the macro /REQ for down- and /LIST for uploading. The format fof the /REQ file should be plain ASCII, and should contain only filenames. Format is free - means filenames can be on one line each or several on one line separated by space. The /LIST file has the format of a FILES.BBS - files that are not OK or dupe will be skipped. Maxlimit <maximum download limit> ... This is to get around a bug in RA: If a user manages to download more than his limit allows (e.g. through BiModem), RA passes a negative value as the download limit (downloadlimit-transferredKB = less than zero!). RA defines the download limit to be an unsigned integer, resulting in a download limit of ca. 65000K. Users could then take everything. If you specify the highest download limit (including possible uploaded k if you do not use NoNegativeUploads) which you grant your users using MaxLimit, EFT can determine if a limit is invalid and will calculate the correct value. TagFiles [Minimum Baudrate] ... This enables the most complex feature of EFT: The Full Screen File Tagger. With this utility, users with ANSI can tag files they want to download, rather than remembering cryptic filenames. If Autosearch is enabled, the tagger lets the user move around areas, and will inform him of how many files/Kb he has selected in which areas. Naturally, private files, security levels/flags, etc. are not ignored. As a bonus, the file tagger gives your user a global access are which shows all the files from all the areas the user has access to on one list for the user to tag files in. Users can switch to "new files mode" to list only the files which arrived after the last time he logged on. This will, of course, work with the global area section. You may type in a file mask to show only those files which match that mask. The tagger includes a super-fast cached quicksort to sort the files by name, size and date. In addition, to prevent users from having to wait around (even on the biggest file databases, such EFT enhanced file transfer 31.03.92 22:36 Page 32 as mine), the tagger multitasks in such a way as to allow the user to tag files while the tagger is still gathering more information from the file lists. There are only a few limitations, both at the user's end : one, the user must have ANSI graphics enabeled, and also must have a terminal capable of displaying more than 12 lines. The user must have selected a batch protocol, since there is not much point in using a tagger to tag one solitary file. Finally the user must be connected at a baud rate the same as or higher than that which you specified for the parameter of this command. If you omit this parameter, then users will be able to use the tagger at any speed. To give users help on using the tagger, you can use the related display files TAGGER.ASC/ANS and TAGVIEW.ASC/ANS. There are some keys which aren't mentioned on the tagger's screen: * and + scroll the filelist under the tagger's cursor by one line up and down. SPACE sorts the list by the current sort mode (no need to cycle through the modes). The tagger allows speed search: If users are searching for special files, then they can use the filemask feature or the new speed search feature. Pressing Control-A..Z searches for files beginning with the character A..Z. The tagger's cursor is positioned on the first found file. The search does not just work for the first character of a filename, for instance, if a user types ^E^F^T, then the cursor will sit on EFT.ZIP (or whatever archiver format it is in..). This will also work in global mode. Here is a list of all the tagger commands/keys, so that you can easily make TAGGER.ANS/TAGVIEW.ANS: Keys that work in list mode: 7 8 9 move cursor close archive4 6open archive/ view file 1 2 3 A select area ? show online help M enter filemask K switch to keyword search D select display mode (All/New files) N enter date to search for new files F toggle private/public files (if private files there) S change sort mode SPACE sort list again if tagger gathered more information after last search T tag/untag files 5 tag/untag files ESC done, download files if selected R redraw screen * scroll list up + scroll list down EFT enhanced file transfer 31.03.92 22:36 Page 33 Keys that work in view mode: 7 8 9 move cursor 1 2 3 A search again in last used direction F set searchstring and begin to search forward B set direction to backwards and search again ? send TAGVIEW.ANS You cannot download files from archives yet, but you can view the contents of any file - even files within archives! The tagger includes a full screen browser which lets you page through any file, by simply pressing '6'. EFT automatically determines if the file is an archive or not. If it is an archive, EFT will display the directory contained within the archive, plus some technical information. If you press '6' again, EFT will uncompress the file under the cursor and will view it in the same way as before (if a file is not an archive, EFT will just view it). Here, EFT also will let the user view the file and concurrently collect more information on the file. EFT supports all archive formats excluding LBR and MD. The tagger can handle descriptions longer than 46 chars, that will not fit on the screen. It will automatically begin to scroll the description horizontally if the users does not type anything for 2 secs. Also users can force scrolling with the new ">" and "<" commands. A word on archive managers: as modems are getting cheaper, it is my opinion that it is better to download a complete file of, say, 200k in size with a transfer time of 2 minutes, than to extract one file from it in 1.5 minutes and download that file in an additional 1 minute. Viewing is ok to determine which version is included, etc. but extracting and recombining to new formats makes less sense than ever these days. To give non-ANSI users the chance to tag files EFT supports a tagging option also on the download-files prompt: If a user gives 'all*.* /P' when he gets prompted for the downloads he gets also prompted for every occurrence of the all*.* filemask. He then has the following options to select from: T.ag the file S.kip the file N.ext area continue scan with next area E.nd scan end scan and proceed to last chance menu A.bort abort the transfer EFT enhanced file transfer 31.03.92 22:36 Page 34 ?.help sends WANTFILE.ASC/ANS if avail else beep This is of course definable with EFT.LNG. TagFilesMacro <path and name> The path and name of this statement is the full path and name to an XFD/DISP compatible tag file. This means that you can use the tag files from other third party utilities such as RFW and MTS to specify files for downloading. If the specified file is present, then a magic name of /GET will autmatically be enabled at the download prompt. Limit checkers, free files, passwords, etc will all still remain active. See the example EFT.CFG file for further information. HideFiles <seclevel> This gives selected users access to orphan files which are not in FILES/PFILES.BBS. See example EFT.CFG for further information. UserMacro <Name> <Auto> <Descr> <Filemask> [Security] This statement lets you define up to 16 "magic names" or macros for use at the download files prompt. The magic names are of course compatible with autosearch and enhanced file masks. For example: UserMacro EFT Y to_download_latest_EFT EFT*.ARJ 130 will mean that the user can type /EFT at the download prompt to get the latest version of EFT. Please note that the files which you specify here must be present in FILES/PFILES.BBS for them to be transmitted unless you have the HIDEFILES statement in your CFG file. Protocol <efficiency> <letter> <way> <maxfiles> <name> ... General information This keyword is the foundation of EFT. It describes the external protocols which are driven by EFT. I have included all the protocols I could think of in the example CFG file, so you might ba able to get away with not modifying these statements (short of commenting out unwanted protocols) Every protocol statement consists of two lines plus one optional line. The first describes the protocol (i.e. key, efficiency, name, etc). The second contains the interfacing method and the command line which is passed to DOS when running the protocol, within which macros my be used for variable parameters (such as baud rate). The protocol line EFT enhanced file transfer 31.03.92 22:36 Page 35 The first line has the following format: Protocol <efficiency> <letter> <way> <maxfiles> <name> o 'Protocol' is just the keyword. o '<efficiency>' is a percentage that states the <efficiency> is an integer which represents the percentage efficiency of this protocol. In most cases, this is most likely to be within the range 75-95%. For interfacing protocols with 'Other' the efficiency must be set as accurately as possible (it is better for the value to be too high rather than too low). o '<letter>' is the letter that the user types to select this protocol. o '<way>' is a single letter - 'U' tells EFT that this is an upload protocol, and 'D' tells that it is a download protocol. o '<maxfiles>' is an integer stating that maximum number of files which may be transferred with this protocol in one session. For non-batch protocols (i.e. XModem) you must specify '1', and the user must supply the filename and description of the file before starting an upload. For batch protocols (i.e. ZModem) you can specify any appropriate number (20 is no longer the maximum as it was with FileDoor). For batch-protocols which must have all filenames supplied on the command line (i.e. CLink), you may want to limit the number of files to 8 or less (4 or less with AutoSearch<tm> enabled - read "Command Line Overflow", below). o '<name>' is the name of the protocol, and what will be displayed to the user against itss activation key when the user has to select a protocol. This free-format text may be up to 70 characters long. The interface line Now for line two in the protocol statement. On this line we have a protocol sub-type, a space character, followed by the actual commandline passed to Dos when starting the transfer. It has the following format: <method> <commandline with macros> o <method> describes the way EFT will talk to the installed protocol drivers, and how EFT calls the drivers. EFT supports the following methods of interfacing with different protocols: EFT enhanced file transfer 31.03.92 22:36 Page 36 DSZ ... This method tells EFT that the protocol will write to a DSZ compatible log-file. This of course includes DSZ. I have tested this with almost all the DSZ protocols from the 161290 revision. For this reason, the environment variable DSZLOG must be set to an appropriate value, and all protocols writing to a DSZ compatible log file, must write to the log pointed to by DSZLOG. An example batch file line to set the DSZLOG environment variable might be: SET DSZLOG=d:\bbs\dsz.log This could be a shared directory, and EFT will handle concurrent access to this file. If you don't specify that variable, then EFT will use its default value DSZ.LOG which will always be in the temporary upload/download directory that EFT creates before calling the DSZ compatible driver. Note! DSZ stops loggin ifit cannot find DSZLOG, so strange things may happen... Opus ... This tells EFT that the protocol follows the Opus 1.0/1.1x standard for external file transfer protocols. I have tested this with Kermit and MegaLink. With Opus protocols, you may not give any command line parameters - the format of this is fixed within the standard. and EFT will automatically set it up. To choose between the OPUS 1.0 and 1.1x standards, use the behaviour statement OPUS11X (described later). ErrorLevel ... This simply tells EFT that is the protocol exits with an errorlevel of 0, then it is to assume that all of the files were sent, and if a non-zero errorlevel occurs, then EFT is to assume that none of the files were sent. With batch uploads, you can enhance this with the behaviour statement 'arctest' (described later), so EFT will have a chance to divide the good from the bad uploads. Also see 'errorlevel' behaviour statement. Other ... This indicates that the protocol does not create any sort of log, and does not exit with any sort of sensible errorlevel when done. This method EFT enhanced file transfer 31.03.92 22:36 Page 37 can be handled, but in a very makeshift way: EFT calculates how long it SHOULD take to send the files, from the baud rate, file size, and efficiency. EFT will time how long the transfer takes, and if it is near enough the same as the time just calculated, then it presumes that all the files were sent okay. If not, then EFT assumes that no files were sent. Therefore, you whould be very careful when entering the efficiency - an incorrect value could mean that no files are transfered properly with this type. This is the worst way of defining a protocol method, and should be only used if you really have to. Using the arctest behaviour statement would help to correctly identify good uploads. CDS ... This is the Call-Data-Specification method used by newer protocol drivers like the superb MPt protocol from Microtech systems. Like the DSZ method it communicates with the driver via a logfile. You must either specify an environment variable called CDSLOG like: SET CDSLOG=d:\bbs\cds.log If you do not set this variable, the EFT will use the default CDS.LOG which will always be placed in the temporary upload/download directory. Another way to tell the driver (not EFT) what log to use is via the special installation program which comes with the protocol itself. With MPt, use MPtset to set the correct name for the CDS log file. MPt allows either CDS or DSZ logging. You should use CDS where possible, since it is safer and provides more information than DSZ logging. Make sure that you set the EFT path to the CDS log file the same as in your protocol's setup program. INTERCOMM ... This if the logstyle Bimodem uses. Instead of implementing a static interface special to Bimodem, I decided to do it a more general way. EFT does not know that it drives Bimodem, it simply knows that it has a protocol that uses an intercomm-style log and is capable of fullduplex transfers - so if a second full duplex protocol with intercom logging come along in the future, EFT will be able to drive it... Have a look at EFT.CFG to get an idea of how the parameters work to drive BiModem the right way. EFT does checking for received files on EFT enhanced file transfer 31.03.92 22:36 Page 38 downloading and will process downloads in upload mode. It passes time and byte limits on the command line to BiModem, and will get the right file descriptions from the intercom file. Of course the BiModem received descriptions are truncated to desclen length, and EFT takes care of the minimum, asking the user for a longer description if the recieved one is too short, or invalid. GIF resolution and the name of the uploader will be added as normal if those features are enabled. You can define the name and path of the intercomm-style logfile to suit your needs. Simply set the environment variable ICOMLOG to the path and name of the log you would like to use. Normally you would point to the temporary upload/download directory be leaving out the path in the name. EFT will assume a name of "INTERCOM.LOG" if you omit the environment variable. EFT will create a BIMODEM.PTH default) style file in the temporary upload/download directory which will tell BiModem which files to transfer. EFT will use the name "BIMODEM.PTH" as the default unless you set the BIPATH environment variable. I recommend that you use the default value by simply skipping the environment variable, however there is no restriction to do so. Thirdly, Bimodem has to know from which paths it is allowed to send files. EFT will create a file called "BIMODEM.DIR" in the temporary upload directory containing the paths of the fileareas that are available to the user. Note that a filearea is only added if normal, private level and flag settings match the users settings. You may use the environment variable BIDIRS to define another path and name to use. EFT is able to generate passworded files for BiModem so that no user is able to get passworded files by adding them to the list during transfer. If you put "*W" on the BiModem command line in EFT.CFG, EFT will generate this file in the temporary upload directory (the default) or in the path defined by the BIPASS environment variable. As for all the environment variables, $1 in the paths will be replaced by the path of the actual node number EFT is working on. This is good for multi line systems with a shared EFT.CFG. EFT enhanced file transfer 31.03.92 22:36 Page 39 There are four macros to pass information to BiModem on the command line. *A gives the contents of BIPATH, *D, BIDIRS, *W, BIPASS and *I the contents of ICOMLOG. These will, of course be replaced by the default values if the environment variables are not ser. BiModem can check uploaded files against a file of pathnames. This is a plain text file, and should contain all the pathnames to all your areas, so that no files are sent to you which already exist on your system. As this is a nearly static file, EFT will not create it - so you must create it if you want BiModem to do this checking. Skip the /J?:\path\file.ext parameter from EFT.CFG. TIP: One thing to remember: If users are out of download limit, they are still allowed to upload via Bimodem. Make sure to put a /S1 parameter on Bimodem's commandline in EFT.CFG for upload mode. This will prevent Bimodem from accepting added download requests while upload transfer is in progress. (Users - some of them are smart!) o <commandline with macros> is the command line which EFT uses to run your external protocol driver. If the file with the driver isn't found in the given directory EFT will search the DOS path for it. It will also automatically search for a .EXE or .COM version of the file, so you can omit the extension. As stated you have several macros which are replaced with information describing the runtime situation: o $1 or *P ... the port in use (1=COM1) o *O ... the used port minus one (0=COM1), if you have a protocol driver that takes 0 as COM1: o $2 or *B ... the baud rate o $3 ... the response file for DSZ or compatible drivers o $4 ... a list of the files to be transferred with full paths, so you better restrict the maximum number of files to be transferred with this protocol to prevent a commandline overflow. o *C ... complete path and name of the active command processor (great to run EFT enhanced file transfer 31.03.92 22:36 Page 40 batch files etc. see also behavior 'goodfile') o *H ... placing *H somewhere on the commandline tells EFT to leave the FOSSIL driver HOT (initialized) on shelling to the protocol driver. Otherwise the FOSSIL is deactivated each time EFT calls up a child program. EFT initializes the FOSSIL on return from the child process in any situation. o *N ... the node/line number o *T ... user's time limit in minutes o *S ... user's downlaod limit in kilobytes o *K ... user's download limit in kilobytes o *A ... contents of BIPATH environment variable or default "BIMODEM.PTH" o *D ... contents of BIDIRS environment variable or default "BIMODEM.DIR" o *W ... contents of BIPASS environment variable or default "BIMODEM.PWD" o *I ... contents of ICOMLOG environment variable or default "INTERCOM.LOG" o *9 ... number of actual filearea You can put the contents of ANY environment variable on a protocol's commandline in EFT.CFG now: Use: %NAME_OF_ENVIRONMENT_VAR% Example: dsz dsz.com port $1 speed $2 sz %dszlog% The behavior line EFT introduces a third line to the protocol statement. This line describes special abilities of that specific driver. Here are the legal statements for the behavior line: o ArcTest ... This is used with upload protocols only, and tells EFT to test an uploaded archive for integrity before giving credit to the user. This EFT enhanced file transfer 31.03.92 22:36 Page 41 may take a little while depending on the quality of the used archiver, but as a result, you won't have broken archives on your board, saving lots of angry messages to the _busy_ SysOp. Arctest works with ArchiveExtension: It uses the command you specified on the ArchiveExtension line to run the appropriate testing program. Any $1 macro on that commandline will be replaced with the uploaded file to be tested. The remote user will only see "Checking JohnDoe.Zip ..." message, and for the result a "GOOD" or "BAD". Your local console will be shown all the testing operations. The screen will be restored to what the user is seeing after testing completes. BEWARE! Make sure that you turn off all interactive processing while checking an archive. See also ArchiveExtension keyword o ArcExitinfo If this is specified on the behaviour line, then every time EFT exits to perform arc-testing, EFT will write a small EXITINFO.EFT file which contains information on three lines: <full path and name of file to be tested> <full name of the uploader> <description of the archive given by the user> On return from the testing, EFT will read in this file and store lines one and three in the appropriate FILES.BBS. Line two will be ignored. This means that you can change archive formats, names, extensions and add customary bits to descriptions during the testing, write them to this file, and EFT will change and add the information to the FILES/PFILES.BBSs. o ErrorLevel=<good errorlevel> ... This is for protocols which insist on using the errorlevel interface method for talking to BBS systems. You can definge what errorlevel should be taken as a successful result from the protocol driver. If for some unknown reason the protocol returns an odd non-zero value errorlevel on a successful transfer, you may use it with EFT. Errorlevel may not be used in conjunction with the following goodfile statement. Make sure that you do not confuse the errorlevel statement for interfacing with the protocol with the errorlevel statement on the behaviour line! o GoodFile=<path and name of goodfile> ... EFT enhanced file transfer 31.03.92 22:36 Page 42 A new unique feature to EFT is the chance to run protocol drivers from a batchfile. You may not think that this is much of a feature, but think of this: You can now run any driver, even those which need special conversions to be made, or interaction files to be created. Anything is possible now : you can run anything you want in the batch file before returning to EFT: any utility that you want to run to process an uploaded file.... This is great for .MOD or .GIF files. As I said - do anything you want in the batch file, and if you find that the files are all correct, you simply let the batch file create the file you specified behind the goodfile statement. You can use any name for the goodfile and also any path - even on a RAMdrive if you so wish. If on return EFT finds a file of that name and path, it assumes the complete transfer to be good, charges for downloads and gives credit for uploads. If a file cannot be found, then EFT assumes the transfer to be bad. Note that you cannot use it in conjunction with the errorlevel behaviour statement. You should use the goodfile statement in conjunction with the *C macro on the interface line. o Opus11X ... This is to run protocol drivers that use the OPUS method of interfacing and are written for OPUS 1.1x systems. EFT will perform special necessary operations and give additional commandline parameters o SendInfos ... Your users are going to like this one! Now they get an additional text file with all the descriptions of the files they requested for downloading. The descriptions are taken directly from the FILES/PFILES.BBS, and it also works with AutoSearch. They are all placed in a file either called FILES.EFT, a name of your choice, or a name relating to the day and time of the download. The file will include all information on files which were skipped for whatever reason (download limit, ratio, time limit or password errors, etc.) FILES.EFT is always a freefile, so no one can complain that they were charged for an additional file. SendInfos only works on downloads. See also InfoFile. EFT enhanced file transfer 31.03.92 22:36 Page 43 o GetInfos ... Your users are going to like this one, too: it is the opposite of SendInfos, and allows users to give descriptions of files in a text file of FILES.BBS format (an called FILES.EFT) and upload it with their files. EFT will then take the descriptions of the files from the FILES.EFT and automatically add them to the FILES/PFILES.BBS. If for any reason a description from this file is invalid, the user will be prompted for a description for that file, with the original description as the default for the user to alter. This is great for users who upload large amounts of files or for those who upload large files and then go to bed - normally EFT and the BBS will time out. If you do not specify GetInfos, and a user sends a file called FILES.EFT with an upload, it will be processed just as a normal upload. See also InfoFile o NoLeading@ This skips the leading @ character from the $3 response file on the interface line. So you can also run drivers, that support response files, but do not like @ characters in the filename. Beware DSZ and MPt need a leading @ character in their responsefile. o Resume On uploading this statement maes EFT swap in broken files from the specified break directory to the temporary upload directory so that the external protocol can resume the transfer. If you run a multiline system, this should be a shared directory so that users can resume transfers from line 1 on line 100, too. EFT will give a message to the remote user that it is swapping a file in for him to resume, and enables a special hint on the 'give filename to upload' prompt, because the swapping in of files can only be done if the names of the files to be uploaded are known to EFT. The biggest of a generation of broken files will always be swapped in. o Cls When running the external driver, the status line may get overwritten when the output from the driver isn't formatted (like DSZ). To avoid this, you can tell EFT to clear the screen when EFT enhanced file transfer 31.03.92 22:36 Page 44 shelling to leave room for the protocol's information. o Window=UpperLeft_X,UpperLeft_Y,LowerRight_X, LowerRight_Y,Attribute,Borderstyle EFT introduces the unique feature to run external protocol drivers in a window! This is specially useful if you let EFT run drivers which use DOS for their screen-I/O, and that have some sort or unformatted output (like DSZ). You can specify the coordinates of the window and the screen attribute in which the driver should appear on the screen. This works perfectly with the three swapping methods (see there), and you can also use windows when you do arctesting (see behaviour statement Arctest). Note that SysOp-DOS-shells via ALT-J are never windowed. The border parameter will put a frame around a child process' window. Usage of the bits in the border parameter: +Display child's parameters ! ! bit7 xxxx xxxx bit 0 ! !! ! Type of frame: ! Display name 0= no frame of child process as window title 1= ┌─┐ └─┘ 2= ╔═╗ ╚═╝ 3= ╓─╖ ╙─╜ 4= ╒═╕ ╘═╛ Example: window=10,10,70,20,27,129 will put a type 1 frame around the child process and display its name but not its parameters as the window title (all in cyan on blue). o ArcWindow=UpperLeft_X,UpperLeft_Y,LowerRight_X, LowerRight_Y,Attribute,Borderstyle EFT enhanced file transfer 31.03.92 22:36 Page 45 ArcWindow defines the window for arctesting (see behaviour ArcTest). So you can have a non-windowed file transfer but a windowed arc checker. o SlowBIOS Running external drivers in a window can cause interrupt problems on machines with slow video BIOSs. These BIOSs disable interrupts too long, causing data loss at the serial port. If you enable SlowBIOS, EFT will keep track of the drivers output and its interrupt activity switching RTS on and off as the driver writes to the screen or lets the screen scroll upwards. This is only needed on uploads to your systems, that are faster than 14400 bps in conection with the slow machines BIOS. o LeaveUploads This is to let protocols transfer uploads into different paths that the temporary upload directory. EFT retrieves the path information from the driver's log, and will find and move the uploads even if they are not received into EFT's temporary upload directory. Enableiing LeaveUploads makes EFT leave the uploads where they were received. EFT then creates/updates PFILES/FILES.BBS in the receive path. Credit is still given. If LeaveUploads is not enabled, all uploads are moved into the actual filearea. Useful to establish a 'general upload' file area. o NofilesOK This is used for drivers which hadle file requests internally (Like Bimodem). Users are allowed to press Enter at the 'what file do you want to download' prompt to let the driver handle it. EFT enhanced file transfer 31.03.92 22:36 Page 46 6. Supported files ------------------- EFT supports some of the various files that RA uses to output sysop definable texts to the user. EFT has also some files of its own whose use is FileDoor compatible. Here is the list of the files you can install for EFT. Simply create a file in your RA TXTFILES directory with the extension .ASC for non-ANSI users, and .ANS for ANSI users: System files System files control special parameters and attributes of your system. They must reside in your RA system directory. FILES.CTL ... FILES.CTL contains information on files in your filebase: It allows you to mark any downloadable file on your system as free and/or password protected. The format of this file is: <filespec> [/FREE] [/PWD=xxx] [/UNWANTED] Example: \RAFILES\EFT_100.ZIP /FREE \RABETAS\RABETA.ZIP /FREE /PWD=RACCESS If you do not give a pathname the path will be relative to the actual filearea. Note that EFT supports enhanced filemasks like *3*i?t.ZIP or similar every time it comes to pathes or filemasks. Here, EFT_100.ZIP is free. Downloading it will not affect the user's download statistics. Note that even though the file is free in this regard, the user must still have enough time remaining for the download. You can also use the FreeFile statement in EFT.CFG! RABETA.ZIP is both free and password protected with the password RACCESS. The user must supply the correct password before being allowed to proceed with the download. Passwords are case insensitive and not a maximum of 15 characters in length but instead passwords can be 255 chars long. Both features work with 'download specific file' (see -dd<file> switch in the command line section). Free files are shown on a special line at the last chance menu. BADFILES.CTL ... EFT enhanced file transfer 31.03.92 22:36 Page 47 This file allows you to specify a list of files that users may not upload. Simply specify one file per line (wildcards and paths valid), for example: *.GIF NORTON*.* c:\der\plums\sack\geht.um Would not allow any files matching either of these two patterns to be uploaded. Note that EFT supports enhanced filemasks like *3*i?t.ZIP or similar every time it comes to pathes or filemasks. TIP: On my board I have the problem, that every time I erase old stuff from the fileareas, users upload it again several days later because the dupe checker does not find any file(s) of that name(s) any more. So I did the following: I created a special directory called d:\unwanted and everytime I delete stuff from the board I do not erase it at once: I hurl it to that 'unwanted' area, so that the FILES.BBS of that area gets the entries. Later I erase the files from the unwanted directory (beware not to erase FILES.BBS!). So the anti duper will search the hidden unwanted area and will reject any file that is contained in the FILES.BBS. You can also use the phonetic anti duper with this, and if you set the security levels appropriately, the anti duper my not ask the user if files in the unwanted area are real dupes, instead he will say "file exists" and thats all ... LIMITS.CTL ... This file allows you to specify, for each security level, a daily time limit, file download limit for each baud rate, and optional file ratios, either in number of uploads to number of downloads, or in total kilobytes uploaded to total kilobytes downloaded. The format of the file is as follows: <Sec> <Time> <300> [1200] [2400] [4800] [9600] or: <Sec> <Time> <300> <1200> <2400> <4800> <9600> <R#> [RK] Where <Sec> is the security level, <Time> is the daily time limit, <300> to <9600> are respective download limits depending on what baud rate the user calls at. <R#> is the ratio of uploads to downloads, and [RK] is the ratio of uploads in K to downloads in K. If you only specify a download limit for say 300, 1200 and 2400 baud, the download limits for the higher baud rates default to the highest baud rate specified, in this case the limit set for 2400 baud. EFT enhanced file transfer 31.03.92 22:36 Page 48 If you specify a ratio by number (R#) value, then the user will be required to upload one file for every n they download. Similarly, setting the ratio by K will allow the user to download only the specified kilobytes of files per 1 kilobyte uploaded. This is fairly complicated, so look at this example LIMITS.CTL: 5 35 0 10 60 100 200 350 650 900 5 10 20 90 150 250 470 750 900 5 30 120 250 400 600 900 1200 50 300 900 Security level 5 entitles the user to 35 minutes per day, but no downloads. Security level 10 entitles the user to 60 minutes per day, 100k of downloads at 300 baud, 200k at 1200 baud, 350k at 2400 baud, 650k at 4800 baud, and 900k at 9600 baud or faster. In addition, the user must upload at least one file for every five downloaded, and may not download more than ten times the total size of files uploaded. Security level 20 entitles the user to 90 minutes per day, 150k of downloads at 300 baud, 250k at 1200 baud, 470k at 2400 baud, 750k at 4800 baud and 900k at 9600 baud or faster. In addition, the user may only download five times the number of files he/she uploaded. Security level 30 entitles the user to 120 minutes per day, 250k of downloads at 300 baud, 400k at 1200 baud, 600k at 2400 baud, 900k at 4800 baud and 1,200k at 9600 baud or faster. There are no ratio restrictions. Security level 50 entitles the user to 300 minutes per day, and 900k of downloads at all speeds without any ratio restrictions. FLSEARCH.CTL ... If you want to use a FLSEARCH.CTL style file for your fileareas specify the complete path and name of the file here. Note that EFTs advanced private files and security flag support is turned off if you use Flsearch. FILES.EFT ... If you use SendInfos or GetInfos on your behavior lines, the descriptions are taken from this file which is created in the temporary download directory, and is received with uploads to the temporary upload directory. You can set the name of this file to any name you like (maybe your BBS name) using the InfoFile statement in EFT.CFG. EFT.LNG ... This is the EFT language file. All of the build in texts EFT enhanced file transfer 31.03.92 22:36 Page 49 are definable through this file. There are over 150 texts you can define and several macros you can use on each line. Also EFT.LNG has a special format: #label_first_language language definitions language definitions language definitions language definitions ... #label_second_language language definitions language definitions language definitions language definitions ... You give the label behind the Language statement in EFT.CFG, so that EFT knows what definitions to read (see there). EFT will read string definitions only if they are needed, and will store often used strings in memory for faster retrieval. To adapt the build in texts to your native language EFT brings you several macros: (_) a SPACE (used to add trailing spaces) (|) a CR/LF (^) the defined highlite color (empty for non-ANSI users) (v) the lowlite color (empty for non-ANSI users) $1,$2,$3,$4,$5 output macros. Their contents depent on the place where EFT uses that particular text line. Example: You are $1 kbytes above the limit. ((char1|char2)) This is somewhat complicated. I call this a "map macro". It replaces hard coded input in prompts with user definable values. For instance let us assume a standard yes-no prompt. You can replace the text that is sent easily within this language file. But EFT will still insist on using the english hard coded Y char for YES and N char for NO. Mapping Y into a J char you will have a german version of the hardcoded english prompt. So put a ((Y|J)) macro somewhere on the line where you define your german text for the given yes-no prompt, and EFT will take a J char to be the YES answer to the given prompt. Answering Y to the now mapped prompt will cause in a beep EFT enhanced file transfer 31.03.92 22:36 Page 50 and rejection of the Y answer as it is no longer valid. Map macros do not produce output. Note that the settings made via the YesNo statement in EFT.CFG stay also active. Let us have an example: > Enter up to $1 filenames.(_) You know this. It is part of the hardcoded texts, that can be replaces with the UPHINTS.A* display file. You see a $1 output macro there. EFT will replace that with the number of files that can me transferred with the actual selected protocol. Note also the (_) sign at the end of the line. This will add a trailing space. This maybe needed here because more hints may be placed on the same line. If you are in need of more lines you can break a line with the (|) CR/LF macro. Lets map something: As english is the default language to EFT there are no mappings in the #ENGLISH section of EFT.LNG. But let us do a mapping as an example: Last chance! ... <(^)M(v)>ore files, ... You know this also. It is an extract from the last-chance menu. Now we want the <M>ore files to be replaced with A<D>d files. So we simply replace the text on that line. But EFT will still use M to go to the more files prompt. So we simply map M into D via ((M|D)), so this may look like this: Last chance! ... A<(^)D(v)>d files, ... ((M|D)) It does not matter where you put the mapping macro ((M|D)) as it will not produce output. Play around with macros in EFT.LNG and you will soon know how the thing works, and see how powerful that is: For example you can completely redesign the build in "select-protocol" menus with other colors or you give the protocol description first and the select key at the end of each line. You want MM-DD-YY date format when using the file tagger? No problem. Simply change line 80 to your needs. You don't like the way EFT puts picture resolutions into GIF or PCX descriptions? No problem. Line 75 will do it for you. Note that the line number I told you here refer to their relative positions behind the #ENGLISH label (or whatever you use). EFT enhanced file transfer 31.03.92 22:36 Page 51 Display files are what I call files which replace standard messages and prompts that are hardcoded into RA and EFT. You can mainly have two versions of a display file: One for users using ANSI on your board, and one for those who don't. If EFT doesn't find an ANS file for some prompt, but does find the ASC alternative, then EFT sends the ASC file instead. If that can't be found either, it uses the hardcoded default message. Note that ONLY the following embedded control codes are active when sending those files. EFT will treat all embedded codes not listed here as normal characters, and will send them unmodified to the remote site. These codes are only active if you enable the EmbeddedCodes statement in EFT.CFG (see there). This is to keep the decrease in speed as small as possible on systems that make no use of any embedded control codes. Neither does EFT send screen clearing codes at the beginning of a display file nor does EFT insert a Press [Enter] to continue pause at the end of a dispaly file. You will have to program that via CTRL-L and CTRL-A. This is for added flexibility. Character ASCII# Combination Information displayed ------ ----------- --------------------------------------- 65 ^FA Users full name 66 ^FB Location 67 ^FC Password 68 ^FD Business/Data phone number 69 ^FE Voice/Home phone number 70 ^FF Date of last call 71 ^FG Time of last call 79 ^FO Security level 80 ^FP Total calls to the BBS 81 ^FQ Number of uploads 82 ^FR Kilobytes of uploads 83 ^FS Number of downloads 84 ^FT Kilobytes of downloads 85 ^FU Minutes used today 87 ^FW First name only 51 ^F3 Handle (empty on RA004 systems) 52 ^F4 Date of first call 53 ^F5 Date of birth 54 ^F6 Subscription expiry date 57 ^F9 File ratio (number of files) 58 ^F: File ratio (kilobytes) 65 ^KA Total system calls 66 ^KB Last caller (any line) 70 ^KF Number of times user has paged sysop 73 ^KI Actual time (HH:MM:SS) 79 ^KO Time Remaining in minutes 81 ^KQ Daily time limit 82 ^KR Current baud rate 84 ^KT Daily download limit (in K) 87 ^KW Line number (as set on command line) 88 ^KX TERMINATES THE CALL 90 ^KZ Name of current template file area EFT enhanced file transfer 31.03.92 22:36 Page 52 50 ^K2 Number of current template file area 37 ^K% amount of k left for downloading today 92 ^K\ Erase to end of line (ANSI only) 01 ^A Wait until the [Return] key is pressed 02 ^B Disable aborting with the "S" key 03 ^C Enable aborting with the "S" key 04 ^D Enable the "Continue?" prompt 05 ^E Disable the "Continue?" prompt 23 ^W Pause for one second Embedded codes for display files AND all prompts and texts in EFT.LNG: ^K[cc ... Set color regarding the following table: Foreground Background Colours (2nd "cc" digit) (1st "cc" digit) ------------------ --------------------- 0 - Black 0 - Black 1 - Blue 1 - Blue 2 - Green 2 - Green 3 - Cyan 3 - Cyan 4 - Red 4 - Red 5 - Purple 5 - Purple 6 - Brown 6 - Brown 7 - White 7 - White 8 - Grey 9 - Bright Blue A - Bright Green B - Bright Cyan C - Bright Red D - Bright Purple E - Bright Yellow F - Bright White 0 - Flashing Black 8 - Black 1 - Flashing Blue 9 - Blue 2 - Flashing Green A - Green 3 - Flashing Cyan B - Cyan 4 - Flashing Red C - Red 5 - Flashing Purple D - Purple 6 - Flashing Brown E - Brown 7 - Flashing White F - White 8 - Flashing Grey 9 - Flashing Bright Blue A - Flashing Bright Green B - Flashing Bright Cyan C - Flashing Bright Red D - Flashing Bright Purple E - Flashing Bright Yellow F - Flashing Bright White EFT enhanced file transfer 31.03.92 22:36 Page 53 Examples: 43 - Red foreground on a Cyan background. 01 - Blue on a black background. FB - Flashing Bright White on a Cyan background. A colourful "ENTER" - [01E[03N[05T[04E[0ER HLP_UP.A??,HLP_DOWN.A?? ... This file is sent if a user types '?' in the protocol selection menu. Depending on if the user is up or downloading, HLP_UP.A?? or HLP_DOWN.A?? are used. These files are quite similar to the XFERHELP.A?? file which RA uses, and in fact if EFT does not find its special files for up and downloading, it uses the general protocol information from RA's XFERHELP.A??. If XFERHELP.A?? could not be found either the '?' menu topic will be disabled, and the user will get a nasty beep if he typed '?'anyway (as for all illegal keys). The files should all contain information on the installed protocols. UP_CMD.A?? ... This file is sent if a user types '/?' on the give-filename-for-upload prompt. I should contain general information on uploading files to your board with information on how old files you allow on your system, and what credit is given to what sort of files. See ULMultiply, UploadCredit and UpDayCredit statements. DWN_CMD.A?? ... This file is sent if a user types '/?' on the download files commandline. I should contain general information on downloading from your board, using the file tagger, request lists and other features. EFT_UP.A??,EFT_DOWN.A?? ... You can replace the hard coded protocol selection menu with these files. Note! EFT does not sent a trailing newline after those files. This is to let the cursor stay where the last ANSI sequence in the .ANS versions had positioned it. So make sure that you have an additional newline in your .ASC versions. Those files were named FD_UP.A?? and FD_DOWN.A?? in FileDoor! UPHINTS.A??,DWNHINTS.A?? ... You can replace the hard coded hints, that are shown after the user selected the protocol with these files. Cursor is left were you put it. On uploading a Filename 1: prompt follows this file, on downloading filenames are accepted EFT enhanced file transfer 31.03.92 22:36 Page 54 immediately after the last character of the file is sent. EFT_CMD.A?? ... This file enables the /? topic on the 'enter files to download' prompt. If its found and sent the users gets information on how to enter downloads, what to consider on downloading, on autosearch etc. If it is not found the /? prompt will not be displayed, and will not be active. File was called HLP_CMD.A?? in FileDoor. BADFILES.A?? ... This file is displayed if the user attempts to upload a file that is listed in BADFILES.CTL. DNLDHRS.A?? ... This file is displayed if a user attempts a download outside the allowed hours as defined in EFT.CFG. RATIO.A?? ... This file is displayed if the user tries to do a download which would exceed his/her ratio of number of files. Note! If you use this no additional information will be shown to the user (how many files, and which files exceeded the ratio). However the user will be asked after a 'Press [Enter] to continue' prompt, if he wants to transfer the remaining files. This is of course only useful for downloads. RATIOK.A?? ... This file is displayed if the user tries to do a download which would exceed his/her ratio of K of uploads to K of downloads. Note! If you use this no additional information will be shown to the user (how many files, and which files exceeded the ratio). However the user will be asked after a 'Press [Enter] to continue' prompt, if he wants to transfer the remaining files. This is again only useful for downloads. TOOSLOW.A?? ... This file is displayed if a user tries to log on at a speed lower than the minimum required to log on to your system as defined in EFT.CFG. STARTCHT.A??,ENDCHT.A?? ... STARTCHT.A?? is displayed when the sysop breaks in for a chat via ALT-C. ENDCHT.A?? is displayed when the sysop terminates chat mode. EFT enhanced file transfer 31.03.92 22:36 Page 55 TODAYK.A?? ... This file is displayed if the user attempts a download which would exceed his/her daily download limit. Note! If you specify this no additional information will be given (how many files, and which files exceeded the ratio), because the hardcoded routines will not be used. PWDERROR.A?? ... This file is displayed if the user attempts to access protected files, and did not know the correct passwords. TAGGER.A?? ... This file is displayed if the user selects the ? key on the file taggers menus. Users must have ANSI enabled to use the tagger, but TAGGER.ASC is valid and processed anyway. TAGVIEW.A?? ... This file is displayed if the user selects the ? key on the file browsers menu. TAGAREA.A?? ... This file is displayed if the user selects the ? key on the file taggers area selection. EFTCHAT?.A?? ... Textmacro files EFTCHAT1.A?? .. EFTCHAT9.A?? are sent from chat mode if sysop presses ALT-1 .. ALT-9. No embedded codes allowed in EFTCHAT1.A?? .. EFTCHAT9.A??. The sysop can still type while file is being sent. ALT-0 aborts sending of textmacro file. If in split screen chat, the textmacro file is sent through the sysops window. Great for phrases, byestrings etc... ALT-S sends any file from chat mode (sysop gets prompted for full path and name). BADPIC.A?? ... This file is sent every time an uploaded picture file (GIF/PCX etc.) is rejected. WANTFILE.A?? ... This file is sent every time the user pressed ? on the low-tech tagger menu. EFT enhanced file transfer 31.03.92 22:36 Page 56 7. Samples,Notes ----------------- Ok, to avoid you run away screaming, I had better give you some samples: 1. Commandline Samples EFT.EXE Depending on if EXITINFO.BBS could be found, EFT will do two things: 1) If EXITINFO was not found, EFT brings up the local test mode. In this mode it will act like if a user is online, except it will not write any EXITINFO.BBS. Try chatting with yourself etc. everything works. 2) If EXITINFO was found EFT will assume some defaults because you did not give any additional parameters: o COM1: is used, o time remaining is calculated from EXITINFO.BBS o AutoSearch is enabled and EFT performs a download o the configfile defaults to EFT.CFG and but be in the actual directory EFT.EXE -cC:\FileDoor\MyConfig.Cfg -ddschnupf.zip -ac:\ -wtest Perform download of the specific file C:\SCHNUPF.ZIP. Additionally the user has to give the password 'TEST' to get it. COM1: will be used, and the baudrate is determined from EXITINFO.BBS. EFT.EXE -du -a*0 -p*P -b*B -t*T *M Performs an upload to a RA system. This takes advantage of RA's commandline macros. I use this one to upload to my board using template paths (see RA doc). EFT.EXE -dd -a*0 -p*P -b*B -t*T -wmikesmegas *M Performs a download from an RA system using the actual template filearea. Additionally the user has to give the password 'MIKESMEGAS' to get any byte from the board. 2. General Notes 1. HotKeys ... EFT brings the SysOp the following hotkeys: EFT enhanced file transfer 31.03.92 22:36 Page 57 ALT-C ... chatmode with colors (ANSI only) and automatic word wrap. On return EFT stays right where you pressed the key, so this will work in textfiles, menus, prompts or wherever EFT may be when you want to chat. ALT-H ... hangs up on the user with line-noise simulation ALT-J ... swapped DOS shell, returns to exactly the position you pressed the key. Availiable everywhere in EFT. Automatic use of XMS/EMS memory. ALT-S ... When in chat mode lets sysop send any file to the users side. He gets prompted for the full path and name. File with embedded codes are allowed. cursor up ... increment time limit by 1 minute cursor down ... decrements time limit by 1 minute cursor left ... increment download limit by 1 kbyte cursor right ... decrement download limit by 1 kbyte home ... increment upload kb by 1 kbyte end ... decrement upload kb by 1 kbyte ctrl. home ... increment upload kb by 10 kbytes ctrl. end ... decrement upload kb by 10 kbytes pgup ... increment download kb by 1 kbyte pgdown ... decrement download kb by 1 kbyte ctrl. pgup ... increment download kb by 10 kbytes ctrl. pgdown ... decrement download kb by 10 kbytes EFT enhanced file transfer 31.03.92 22:36 Page 58 Overview: Time UP | Uploads UP \ | / Downloads UP 789 Limit down -456- Limit Up 123 Uploads DOWN / | \ Downloads DOWN | Time DOWN Ctrl = Factor 10 All changes to the userinfo are saved into the users record. 2. Networks and Multitaskers ... EFT will support networks that use SHARE.EXE to access files from different sides. It will detect SHARE and switch to locking mode automatically. Note that some drivers do not support shared access to log files etc. E.G. Bimodem locks up its logfile during a transfer, and so no other protocol from other lines can write to that file, and may hang your system with a Network Error: File in use - Retry Abort Ignore ... To get around this simply direct the logs of the different lines to different logfiles. EFT detects the presence of DESQview, TopView, TaskView, OmniView, MS Windows and IBM 3270 PC multi-tasking systems. 1) Timeslicing: EFT will release ticks to the multitasker if it is momentary idle. 2) Virtual Video Memory Support: EFT will use MTVB virtual memory for direct screen writing. So be sure to set the task EFT is running in to the following statements: Directly writes to video Memory: N Virtualize text and graphics : N Display graphics : N 3. CD-ROMs ... EFT introduces a new method of accessing CD-ROM in a fast and easy way as there are several problems with the conventional RA/SBBS read-only media support: Nearly every CD on the market consists of hundreds of directories. How to connect those into a BBS? Installing hundreds of EFT enhanced file transfer 31.03.92 22:36 Page 59 fileareas? No way. EFT now brings you a new FILES.BBS format: <filename + PATH> <filesize> <filedate MM-DD-YY> <description> <filedate MM/DD/YY> <filedate MM.DD.YY> 1) With this you can combine files from different directories TO FORM ONE SINGLE FILEAREA! Note: If you skip the path information from a line in a CD-ROM FILES.BBS EFT will assume the normal filepath to the given file as installed in FILES.RA/FLSEARCH.BBS. 2) In addition I included the filesize and filedate in the new FILES.BBS. EFT will not access the CD when listing the CDROM based fileareas e.g. when tagging files with the full-screen tagger. This gives you LIGHTNING FAST access to CD-ROM files, and lets you even change the filedate of files on the CD-ROM, so if you install a new CD you can have all or several or some or the files on the CD-ROM included in your new-files list. The statement CDROM in EFT.CFG lets you define those areas from FILES.RA / FLSEARCH.BBS, that should be under control of EFT's CD-ROM manager. Be sure you have set the global list-path in RACONFIG and the listpathes for each area in FLSEARCH.BBS. If you erroreously try to let EFT move files into a CD-ROM path (bidirectional uploading into a CD-ROM area), EFT will move those uploads into the break directory. Be sure to use the -au parameter correctly. Be sure to set the ULsecurity for your CDROM areas to an appropriate value (mine are at seclevel=60000) 4. RAM usage This a problem: EFT uses lots of RAM to store configuration information, FILES.RA and other things. Memory Allocation errors will be logged, so increase to RAM size of the task EFT is running in when running under a multitasker. I will work on that, and future version will use less RAM. 5. Fast Modems If you use a modem running with a locked baud-rate (US Robotics, Telebit, AX9224c, Telekom MDG 19K2-31 etc.), you need to edit the command-lines in the configuration file. Two things: 1. Replace all `$2' with the locked baud-rate, i.e. '19200' for most modems. 2. Somehow tell the transfer program that it has to use EFT enhanced file transfer 31.03.92 22:36 Page 60 hardware handshake (CTS/RTS/etc.). For DSZ this is done by including a "handshake both" statement in the DSZ commandline. For the other transfer programs you're on your own... Those transfer programs that use the FOSSIL for modem I/O (i.e. CLink etc.), shouldn't need editing as the FOSSIL will take care of the handshaking and locked baud-rate. EFT itself knows -nothing- about the modem type. It just gets the baud-rate from the BBS, and uses it to calculate transfer times, and to pass it along to the external transfer programs. 6. Hidden files Beware of, that unlike like RA, EFT requires that the file to be downloaded is listed in FILES/PFILES.BBS for the user to download it. Same goes for private files (those listed in PFILES.BBS or PFILES.<no of area> when using global list path)). Users must have enough private files access and private access flags for that specific area to download private files from it. In no case will EFT send one of the following files: FILES.BBS, PFILES.BBS, RA.KEY, EFT.KEY. 7. Swapping EFT supports three different methods to swap itsself out of memory to give additional room to the protocol driver being run, or if you shell to dos via the ALT-J hotkey. The first and most common method is file swapping: EFT will allocate a swapfile with the name and path you specify behind the SwapDir statement in EFT.CFG. If you do not give a special SwapDir parameter EFT will default to EFT.SWP in the actual directory (that will be the temporary up/download under the actual used filearea. This file will be deleted when swapping is complete). The file swapping method will be available on nearly all systems, except those that do not have 250k available on their HDU. The second method is called EMS swapping, and of course EFT will use EMS memory, if enough of it is available. The EMS memory must conform to EMS4.0/LIM. EMS simulators which reserve a 64k frame in lower memory are supported by EFT. As an additional bonus EFT will copy its overlays to EMS memory to always work full speed on your system. Third there is the XMS swapping method: As a unique feature EFT introduces the ability to swap itsself to XMS memory that is found on every 286 machine and above. So if you do not use a NEAT 286 or 386 machine for your BBS this is the method you will like. EFT accesses XMS memory in protected mode which is lightning fast even though EFT has to switch back and forth to and from protected mode. The only thing you'll have to do to make your 286 machine (or above) XMS EFT enhanced file transfer 31.03.92 22:36 Page 61 compatible is to install the DOS device driver HIMEM.SYS in your systems CONFIG.SYS. HIMEM.SYS will also create a HMA (High Memory Area) your you to use. EFT will not use the HMA, since the HMA is mostly used to swap DOS itself out of the lower memory. EFT will work perfectly with a highloaded DOS and highloaded device drivers. But wait - there is one thing you'll have to give attention to: Some BIOS on some older systems need special parameters to let HIMEM.SYS access your extended memory in protected mode. This parameter is to enable the A20 adress line, and if your BIOS refuses to activate the A20 line automatically when HIMEM.SYS initializes you'll have to force it to do so. If you do not enable the A20 line EFT will still find XMS memory: The High Memory Area. But the HMS is max 64k long, and tha is too small to swap EFT out. Unless you enable the A20 line, EFT will keep on complaining about too little XMS memory and will try to use one of the other methods described earlier. So check with a system utility like MFT of CHECKIT to see if your system runs with A20 active after HIMEM.SYS installation. If that isn't the case, here are the known parameters to make HIMEM.SYS force A20 support : device=HIMEM.SYS /machine:??? where ??? is replaced with one of these: AT for IBM AT WYSE for Wyse TOSHIBA for Toshiba Acer1100 for Acer1100 Hpvectra for HP "Classic" Vectra (AT&T) Ps2 for PS/2 Att6300plus for AT&T 6300 Plus PT1cascade for Phoenix Cascade 8. Limit Checkers There are several limit checkers build into EFT: First there is the daily download limit, that is passed via EXITINFO.BBS. The user will in no case be allowed to take more kilobytes than this value. RA calculates the daily download limit everytime it gets a new EXITINFO.BBS from a door program, so don't wonder if you see different values concerning the daily download limit on the status line in one session. Second, there is the time limit: Users are only allowed to take files if the calculated transfer time won't exceed the remaining time passed via EXITINFO.BBS or the -t commandline parameter. The user may gain additional time if you use the UploadCredit statement in EFT.CFG accordingly. Third there are the ratio limits on kilobytes and time: The user will only be allowed to take that much files so that the limit on files won't get exceeded, even it those files would easily fit into the daily download limit. The same goes for the ratio on kbytes. Those EFT enhanced file transfer 31.03.92 22:36 Page 62 conditions are combined with AND, so if one fails the user will not be able to download that file. To not upset the user, EFT will calculate which files of the requested ones will fit into all of the limits and ratios, and EFT will ask the user if he wants to take those files instead of the complete bunch of files he requested. Of course never is it allowed to take more files than the selected protocol driver is able of transferring in one sweep. 3. Trouble-Shooting and Questions Q: Sometimes EFT says "0 file(s) transferred" after a download, even though the file(s) were sent. A: Try to increase the efficiency for the protocol used by 5 or 10 percent. For more information, please read about "Other" protocols in the "Protocol" section. Did you forgot to enable the driver to log information? Did you set the logfile to an invalid directory? Did you set the environment variables on DSZ and CDS drivers? Q: I wonder if EFT is smart enough to check such things as the callers download-limit, and if he has enough time left for downloading the selected files etc. A: Are you insulting me?! Of course EFT checks those things... However, when a user is going to upload something, EFT does not know how long it will take, and so just makes sure that he has at least 5 minutes left (for typing filenames, descriptions, goofing up, etc.). Q: When a caller uses the "<G>oodbye after transfer" option, EFT doesn't hang up when done, it just returns to RA. A: To hang up on the user, EFT lowers DTR, and then expects the modem to drop carrier. Make -sure- that your modem is setup to hangup when DTR is lowered (either via a dip-switch or by the modem command '&D2'). Q: EFT gave me a "Commandline overflow" error today. Why did this happen and how do I circumvent it? A: It happens when EFT discovers that the length of the commandline it is about to execute, has exceeded 132 characters. This is a limitation in MS-Dos and usually happens when the caller selects a bunch of files to download in one session. To avoid it, lower the number of files for this protocol (check the section "Protocol keyword" for more info). Q: Sometimes I find FILES/PFILES.BBS and corrupted files in my root directory. How can this happen, and what should I do? EFT enhanced file transfer 31.03.92 22:36 Page 63 A: You forgot to set the breakdir statement to a correct directory. Read EFT.CFG Q: EFT doesn't start the protocol driver. What is wrong? A: Well probably everything ... but maybe you set the SwapFile statement to a invalid directory? Read EFT.CFG Q: I cannot get EFT to work on my system. I simply replaced FILEDOOR.EXE with EFT.EXE on the commandlines of my menus. A: You'll have to give the -p parameter if you use a different port that COM1: This is an incompatibility with FileDoor. Please read at least the commented .CFG file. Q: EFT does not show my fancy FileDoor menus. A: Names changed! Read Support file section! Q: I try to run my protocol driver and/or the archiver for testing uploads with a batchfile, but EFT doesn't start it correctly. A: Did you forget to set the COMSPEC environment variable correctly? Q: I want to run a batchfile when arctesting the uploaded files, but EFT always says that the file was good, even if it wasn't and gives credit for bullshit?! A: If you run batchfiles on the arctest commandline you'll have to use the *C macro! Only if EFT finds that on the commandline it will switch to the goodfile handshaking, and for batchfiles always eating up any errorlevel in every situation a zero value is returned. You must program your batchfile that it will create a file named 'GOOD.' in the actual directory (that would be the temporary upload directory that EFT had created for you). Only if EFT finds this it will assume that the file was correct, and will not give credit if the file is missing. Please read the section on arctesting again. Q: I do have EMS in my system, but EFT always swaps to disk? A: Maybe there is too less EMS remaining? EFT will use up to 250k of EMS to swap everything it can grab out of memory to give mayimum RAM to the protocol driver. If EFT could not allocate enough EMS it will swap to disk instead. Q: Yeck! I have EFT.LOG everywhere in my system! A: You forgot to specify a path to the LogFile statement EFT enhanced file transfer 31.03.92 22:36 Page 64 in EFT.CFG. So if EFT want's to log something it will use the actual directory (whatever that may be in that second) creating EFT.LOG if it wasn't there already. Q: On Zmodem transfers EFT complains in the logfile that it cannot find DSZ.LOG. A: Set the DSZLOG variable in your environment, or check if it points to an invalid path and/or filename. I would skip the path on the DSZ logfile. The same goes for CDS protocols. Q: EFT tells me, that I have too less XMS memory though I installed the HIMEM.SYS driver correctly and a HMS is available. A: Maybe your BIOS needs a special parameter to HIMEM.SYS to enable the A20 line to let EFT get more than the 64k HMA in protected extended memory. See section on swapping. Q: My Bimodem does not take all of the parameters that EFT passes. A: Buy a newer version of Bimodem. V 1.24 is minimum. Q: Bimodem does not sent a file, except from the actual directory. A: Two things to remember: First you better put a -a parameter on EFT's commandline! Because you omitted -a and a path statement EFT added the actual directory path to your fileareas. This may be dangerous. Second, you are maybe not using private files, but EFT does! If you have set the private security level to say 65000 and a user has only 50 as his sec level, EFT won't grant access to any filearea, because it may be possible for the user to add private files while bimodem is running. This is a security violation! In this scenario files may only be sent from the actual directory EFT was started from, because this is always added with security zero, private security zero and no access flags. Read complete documentation of RA, SBBS and EFT again! Q: EFT can't find a file while a user is online - if I run it in test mode locally everything works fine. A: You have set the security and/or flags of your fileareas too high. If run locally EFT will assume a seclevel of 65000 - that level seems to match your fileareas setting, but if called from RA EFT uses the passed seclevel, and that seems to be too low. Another possible reason is that you have setup RA to use a global list path (path with ALL FILES.BBS in) via RACONFIG, but you did not move your FILES.BBS to that path! Read RA.DOC again and delete the global lust path setting from EFT enhanced file transfer 31.03.92 22:36 Page 65 RACONFIG. Q: If the file tagger is started, it immediately switches to the file areas selection. If I select an area everything works ok. A: Use -a commandline parameter! 4. Maxima o maximum freefiles statements: 16 o maximum download hour windows: 6 o maximum shutup behavior windows: 6 o maximum archiveextensions: 16 o maximum upload protocols: 32 o maximum download protocols: 32 o maximum files that can be transferred in one sweep: 64 o maximum unwanted statements: 16 o maximum password retries before return to BBS: 3 o maximum fileareas: 200 o maximum lines on BBS: 999 o maximuim TagMacro statements: 16 o maximuim UpDayCredit statements: 16 o maximuim DIZ files: 16